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