Re: v3proto Parse/Bind and the query planner
От | Kris Jurka |
---|---|
Тема | Re: v3proto Parse/Bind and the query planner |
Дата | |
Msg-id | Pine.BSO.4.56.0405171600500.24398@leary.csoft.net обсуждение исходный текст |
Ответ на | v3proto Parse/Bind and the query planner (Oliver Jowett <oliver@opencloud.com>) |
Ответы |
Re: v3proto Parse/Bind and the query planner
|
Список | pgsql-jdbc |
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
В списке pgsql-jdbc по дате отправления: