On Mon, 17 May 2004, Oliver Jowett wrote:
> While doing some v3-related changes to the JDBC driver I ran into a bit
> of a problem with Parse/Bind.
>
> However it seems to interact badly with the query planner; where the
> planner would usually make a decision based on the selectivity of an
> index for a particular parameter value, it instead falls back to the
> more general case.
> This is a bit of a barrier to using Parse/Bind by default. Ideally, I'd
> like a way to say "don't plan this query until you have actual parameter
> values" and have that turned on by default, but I can't find a way to do
> that in the v3 protocol.
I seem to recall Tom Lane speculating about delaying the planning of a
prepared statement until it's first execution so it would have the bound
values and then using that plan with subsequent parameters. In the common
case multiple executions of a prepared query would use values of similar
statistical likelihood, but this wouldn't solve the example you gave if
you executed the plan twice for values that aren't similar. I think this
would be a reasonable compromise position.
>
> The existing strategy of doing parameter replacement on the driver side
> works, but we lose the benefits of passing parameters via Bind.
We also have the possibility of doing selective replacement and binding
other values. This would allow using binary bytea transfers (which are
unlikely to be used in selectivity estimates) while doing parameter
replacement for other values.
Kris Jurka
