24 messages in org.postgresql.pgsql-jdbcRe: Limit vs setMaxRows issue
FromSent OnAttachments
Sebastiaan van ErkJun 21, 2006 2:11 am 
Dave CramerJun 21, 2006 7:56 am 
Sebastiaan van ErkJun 21, 2006 8:48 am 
Kris JurkaJun 21, 2006 8:59 am 
A.M.Jun 21, 2006 9:09 am 
Tom LaneJun 21, 2006 9:46 am 
Oliver JowettJun 21, 2006 3:52 pm 
Sebastiaan van ErkJun 22, 2006 1:35 am 
Mark LewisJun 22, 2006 9:15 am 
David WallJun 22, 2006 9:36 am 
Sebastiaan van ErkJun 22, 2006 1:13 pm 
Marc HerbertJul 10, 2006 1:50 am 
Marc HerbertJul 10, 2006 1:59 am 
Marc HerbertJul 10, 2006 2:05 am 
Oliver JowettJul 10, 2006 11:32 pm 
Oliver JowettJul 10, 2006 11:37 pm 
Marc HerbertJul 11, 2006 2:48 am 
Marc HerbertJul 11, 2006 3:00 am 
Oliver JowettJul 11, 2006 3:45 am 
Marc HerbertJul 11, 2006 5:14 am 
Oliver JowettJul 11, 2006 10:01 pm 
Marc HerbertJul 12, 2006 3:22 am 
Markus SchaberJul 12, 2006 3:59 am 
Marc HerbertJul 20, 2006 11:52 am 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:Re: Limit vs setMaxRows issueActions...
From:Marc Herbert (Marc@continuent.com)
Date:Jul 10, 2006 1:50:58 am
List:org.postgresql.pgsql-jdbc

Tom Lane <tg@sss.pgh.pa.us> writes:

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.

If planning is done at time of creation of the PreparedStatement object (reminder: the example given above has no parameters), then the setMaxRows() call will come too late whatever is the protocol change. I mean: no protocol change can go back in time and "optimize" by not doing useless work already done.

Thanks in advance for pointing out my mistake(s) here.