From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Matthew Hagerty <matthew(at)venux(dot)net> |
Cc: | pgsql-interfaces(at)postgreSQL(dot)org |
Subject: | Re: [INTERFACES] 8K query limit in 6.5? |
Date: | 1999-07-13 16:42:50 |
Message-ID: | 23455.931884170@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-interfaces |
Matthew Hagerty <matthew(at)venux(dot)net> writes:
> ... please make this bigger! Or tell me how and I'll do it. :)
"Find all the places that need fixing, and fix 'em." :-)
The devil is in the details ... and there are a lot of details.
You could probably get some useful functionality just by fixing
frontend libpq's output buffer and the query input buffer in
backend/tcop/postgres.c. The trouble comes in cleaning up all the
details, like fixed-size buffers in COPY, pg_dump, etc etc etc etc.
Michael Ansley seems to be interested in working on this; I'd
suggest getting together with him if you want to help.
> Is it really such a big deal to increase the size of a query that pg can
> handle? I'm talking about the size of a query submitted to pg, from what I
> understand there is no limit on the record (tuple) size that can be
> returned from pg. Is my understanding correct?
There is a (quite unrelated) limit on the size of a tuple that can be
stored on disk, but AFAIK you can construct an arbitrarily large tuple
as the result of computations specified in a SELECT and it will be
passed back to your frontend application without trouble; as long as
you don't run out of memory on either side, that is.
Where we want to end up, of course, is no limit on the size of a disk
tuple either, but the code changes for that are almost entirely
unrelated to the ones that deal with the textual length of a query.
It's best tackled as two independent projects.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Daren Sefcik | 1999-07-13 16:50:17 | RE: [INTERFACES] Three posts and no response 8--( |
Previous Message | Bradford F. Lyon | 1999-07-13 16:34:07 | sub |