Zsolt Varga <redax@agria.hu> writes:
> the TEXT fieldtype how many data can store?
> 8192 bytes?
Yup, same as it ever was. (Actually a bit less than 8K, since you have
to subtract the size of the tuple overhead, not to mention any other
fields that might be in the same tuple.) In reality you probably don't
want to design a database in which tuples are bigger than a K or so.
If your tuples run 4K or more then you can only fit one to a disk page,
which means you waste a lot of disk space.
There has been talk of allowing tuples to span multiple disk pages,
but it's not a simple change.
> I also wonder what's the reason to limit a query to 8192bytes maximum..
> is there any serious problem to have longer queries?
That's a completely separate issue from the maximum tuple size on disk.
It's driven by the size of the text buffers used to hold the current
query.
Offhand I think it would not be hard to fix libpq and the backend to
not have any particular limit on the textual length of a query. They'd
still need to have buffers holding the query, but they could realloc()
the buffers bigger as needed. (So, for example, libpq's buffer size
would be proportional to the longest query you'd asked in a given
session. But the initial buffer size could be much smaller than 8K,
so for the average frontend app this would actually save memory.)
One thing I do not know is whether we'd start to run into any hard-wired
limits in the parser/planner/executor with very large (complex) queries
... Thomas, would the parser go down if you handed it a SELECT with a
few thousand OR clauses?
I'd be willing to fix libpq and the backend as far as the parser input
buffer, if someone else will take responsibility for looking at any
hard-wired limits that might exist downstream of that.
regards, tom lane