From: | Kurt De Grave <Kurt(dot)DeGrave(at)student(dot)kuleuven(dot)ac(dot)be> |
---|---|
To: | Josh Berkus <josh(at)agliodbs(dot)com> |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: parameterized LIKE does not use index |
Date: | 2005-06-23 08:33:18 |
Message-ID: | 42BA73CE.4030909@student.kuleuven.ac.be |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> > 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
database consider
replanning the query automatically once it knows the parameter, or
choose from
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.
thanks,
kurt.
--
ir. Kurt De Grave http://www.PharmaDM.com
PharmaDM nv. phone: +32-16-298494
Kapeldreef 60, B-3001 Leuven, Belgium fax: +32-16-298490
From | Date | Subject | |
---|---|---|---|
Next Message | Radu-Adrian Popescu | 2005-06-23 09:22:17 | Re: Performance Tuning Article |
Previous Message | Elliott Bennett | 2005-06-23 03:19:53 | select distinct on varchar -- wild performance differences! |