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 11, 2006 3:00:33 am
List:org.postgresql.pgsql-jdbc

My reading of the JDBC javadoc and my excessive "pickiness" do not agree with the word "hint" /** * Sets the limit for the maximum number of rows that any * <code>ResultSet</code> object can contain to the given number. * If the limit is exceeded, the excess * rows are silently dropped. OK nothing ever tells you that the server has to behave optimally and never compute anything useless. However in this case you know _for sure_ that additional rows will be useless.

I would assume that if the intent of the spec was "put LIMIT on the query", they would say that.

I think they would never say that, because they are quite careful not to ever try to enforce any kind of implementation/performance detail. They just care about the interface and the external results, any timing consideration always excluded.

So the way they seem to do it, is just to open a 8 lanes wide road to performance in front of you ("if you compute that, it WILL be useless and dropped at some point. Now compute what you want."). My poor english skills would not have called this a "hint". I guess this is just a minor misunderstanding.

Of course I'm assuming here that computing those excess rows has no side-effect. Hopefully this is always the case?!

As it stands all it does from an API point of view is change the behaviour of the ResultSet. Whether that does anything for efficiency is an implementation decision. The driver certainly behaves correctly according to the API, which was my point.

Agreed for sure.