From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com> |
Cc: | pgsql-jdbc(at)postgresql(dot)org |
Subject: | Re: Limit vs setMaxRows issue |
Date: | 2006-06-21 16:46:34 |
Message-ID: | 11362.1150908394@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc |
"A.M." <agentm(at)themactionfaction(dot)com> writes:
> On Wed, June 21, 2006 12:00 pm, Kris Jurka wrote:
>> If you're suggesting that we extended the
>> frontend/backend protocol to include this extra information than that's
>> definitely a feature request, not a bug report.
> The backend protocol already supports maximum row limit if you use the
> extended protocol.
No, it would take a protocol change to add such a thing out-of-line
(that is, not as a LIMIT clause in the query text). The reason is that
the planning is done at PARSE time, or at the latest BIND time. The
row limit field in the EXECUTE message comes far too late to affect the
query plan. EXECUTE's row limit was not meant as anything except a way
to fetch a query result in segments, avoiding the grab-it-all-at-once,
run-out-of-memory syndrome. It is definitely *not* meant to imply that
the client doesn't intend to fetch the whole query result eventually.
I don't have a lot of sympathy for the OP's position that he shouldn't
have to use a LIMIT clause for this ...
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Michael Guyver | 2006-06-21 17:26:33 | Binary tx format for an array? |
Previous Message | A.M. | 2006-06-21 16:10:22 | Re: Limit vs setMaxRows issue |