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/
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 |