Re: Upgrading JDBC driver from 7.3 to 8.4 affected execution plans

From: Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>
To: Maciek Sakrejda <msakrejda(at)truviso(dot)com>
Cc: Boris <boris(dot)partensky(at)gmail(dot)com>, PG-JDBC Mailing List <pgsql-jdbc(at)postgresql(dot)org>
Subject: Re: Upgrading JDBC driver from 7.3 to 8.4 affected execution plans
Date: 2010-10-04 04:00:10
Message-ID: 4CA9514A.4090404@postnewspapers.com.au
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-jdbc

On 04/10/10 11:35, Maciek Sakrejda wrote:
> Could this be related to how planning works with respect to
> parameterized queries [1]? If memory serves, a prepared statement is
> typically planned once and that plan is used each time the statement
> is executed. There can be some issues around this because when you
> have a query like "SELECT * FROM foo WHERE bar > ?", the planner has
> no idea of the selectivity of that predicate if it has to plan the
> query before it knows what the parameters will be. E.g., if it picks
> an index scan and then a query is submitted where ? is 10, if 95% of
> bars are greater than 10, the executor will waste a lot of time
> mucking around with the index where it should just be doing a seq
> scan.

IMO Pg would be well served by supporting something like "EXECUTE WITH
REPLAN" or a PREPARE that doesn't cache the plan, only storing the
parsed statement and handling parameter substitution.

This is in the TODO as "Allow finer control over the caching of prepared
query plans" http://wiki.postgresql.org/wiki/Todo . Perhaps this is
something a few commercial users of Pg might consider getting together
and sponsoring work on?

--
Craig Ringer

Tech-related writing: http://soapyfrogs.blogspot.com/

In response to

Browse pgsql-jdbc by date

  From Date Subject
Next Message Bremer, Gerd 2010-10-04 09:07:41 Re: Upgrade to 9 questions
Previous Message Maciek Sakrejda 2010-10-04 03:35:02 Re: Upgrading JDBC driver from 7.3 to 8.4 affected execution plans