> > Of course, I could modify the application and send different SQL
> > depending on which case we're in or just constructing a query with a
> > literal each time, but is there a way to add a hint to the SQL that
> > would cause the query to be re-planned if it's a case that could use the
> > index? Or can I convince the (Perl) driver to do so?
> There should be an option to tell DBD::Pg not to cache a query plan.
> Let's see ....
> yes. pg_server_prepare=0, passed to the prepare() call.
That does the trick! Now I can have the cake and eat it! (clean code
and high perf)
Now it's tempting to dream of some mechanism that could make the
replanning the query automatically once it knows the parameter, or
a set of plans depending on the parameter. In this case the general plan
was about three orders
of magnitude slower than the specialized plan. But I guess this case is
not all that common
and the developer can work around it.
ir. Kurt De Grave http://www.PharmaDM.com
PharmaDM nv. phone: +32-16-298494
Kapeldreef 60, B-3001 Leuven, Belgium fax: +32-16-298490
pgsql-performance by date
|Next:||From: Radu-Adrian Popescu||Date: 2005-06-23 09:22:17|
|Subject: Re: Performance Tuning Article|
|Previous:||From: Elliott Bennett||Date: 2005-06-23 03:19:53|
|Subject: select distinct on varchar -- wild performance differences!|