 | 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: | Oliver Jowett (oli...@opencloud.com) | |
| Date: | Jul 11, 2006 10:01:24 pm | |
| List: | org.postgresql.pgsql-jdbc | |
Marc Herbert wrote:
OK thanks, now I think I got it: it seems like the JDBC API does not assume you need parameter types to plan the query.
The JDBC API doesn't say anything at all about query planning, AFAIK.
Connection.preparedStatement()
* If the driver supports precompilation, * the method <code>prepareStatement</code> will send * the statement to the database for precompilation.
We don't support precompilation in the sense it's used here, then.
[...]
I am a bit confused about what this discussion is actually about .. do you have a point to make here? What is it that you want to do that the current driver doesn't do well? A fair amount of work has gone into getting query execution working smoothly and efficiently within the constraints of the API already.. Vague high-level handwaving, especially without a clear target, doesn't get us anywhere. For example, it's largely irrelevant to an application whether the query gets parsed by the server at statement creation or statement execution .. at worst, it means you see parse errors at a different point.
We retain the parse/plan results on the server side when it looks like the statement will be reused (using a simple "how many times has this statement already been reused?" metric), otherwise we reparse/replan on each execution.
Could this be compatible with any setMaxRows() optimization? I guess yes, provided the maxRows parameter is considered in preparedstatement matching, just like datatypes seem to be... Maybe this is already the case for non-JDBC PREPARE + LIMIT?
This is all very hypothetical without actual protocol support. I'd suggest you start from a proposed protocol design and work back from there. The limiting factor is likely to be what you can easily support on the server side, not the driver implementation.
-O