Skip site navigation (1) Skip section navigation (2)

Re: Limit vs setMaxRows issue

From: Oliver Jowett <oliver(at)opencloud(dot)com>
To: Marc Herbert <Marc(dot)Herbert(at)continuent(dot)com>
Cc: pgsql-jdbc(at)postgresql(dot)org
Subject: Re: Limit vs setMaxRows issue
Date: 2006-07-12 05:01:47
Message-ID: 44B4823B.6010909@opencloud.com (view raw or flat)
Thread:
Lists: 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

In response to

Responses

pgsql-jdbc by date

Next:From: Oliver JowettDate: 2006-07-12 05:08:36
Subject: Re: executeQuery Locked
Previous:From: Nicholas E. WakefieldDate: 2006-07-12 03:17:56
Subject: Re: how to monitor the amount of bytes fetched in a executeQuery()

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group