

![]() | Start a set with this search |
![]() | Include this search in one of my sets |
![]() | Exclude this search from one of my sets |
![]() | Permalink to these results Paste this link in email or IM: |
| Atom feed for tracking future search results Paste this URL into your reader: |
24 messages in org.postgresql.pgsql-jdbcRe: Limit vs setMaxRows issue| From | Sent On | Attachments |
|---|---|---|
| Sebastiaan van Erk | Jun 21, 2006 2:11 am | |
| Dave Cramer | Jun 21, 2006 7:56 am | |
| Sebastiaan van Erk | Jun 21, 2006 8:48 am | |
| Kris Jurka | Jun 21, 2006 8:59 am | |
| A.M. | Jun 21, 2006 9:09 am | |
| Tom Lane | Jun 21, 2006 9:46 am | |
| Oliver Jowett | Jun 21, 2006 3:52 pm | |
| Sebastiaan van Erk | Jun 22, 2006 1:35 am | |
| Mark Lewis | Jun 22, 2006 9:15 am | |
| David Wall | Jun 22, 2006 9:36 am | |
| Sebastiaan van Erk | Jun 22, 2006 1:13 pm | |
| Marc Herbert | Jul 10, 2006 1:50 am | |
| Marc Herbert | Jul 10, 2006 1:59 am | |
| Marc Herbert | Jul 10, 2006 2:05 am | |
| Oliver Jowett | Jul 10, 2006 11:32 pm | |
| Oliver Jowett | Jul 10, 2006 11:37 pm | |
| Marc Herbert | Jul 11, 2006 2:48 am | |
| Marc Herbert | Jul 11, 2006 3:00 am | |
| Oliver Jowett | Jul 11, 2006 3:45 am | |
| Marc Herbert | Jul 11, 2006 5:14 am | |
| Oliver Jowett | Jul 11, 2006 10:01 pm | |
| Marc Herbert | Jul 12, 2006 3:22 am | |
| Markus Schaber | Jul 12, 2006 3:59 am | |
| Marc Herbert | Jul 20, 2006 11:52 am |

![]() | Permalink for this message Paste this link in email or IM: |
![]() | Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: Limit vs setMaxRows issue | Actions... |
|---|---|---|
| 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.







