Обсуждение: Problem getting plpgsql to choose the right query plan
Hi,
I’m having trouble making plpgsql choose the right query plan for a query. From what I understand from googling around, my problem happens because plpgsql is very eager to cache query plans, and therefore often works with “worst-case-scenario” query plans.
The query I’m trying to optimize is of this type:
SELECT column1,column2,column3 FROM places WHERE upper(placename) LIKE upper($1);
When I run it manually with a constant the query takes something like 30ms, but when it’s run in a plpgsql function it takes about 5 seconds. I’ve narrowed it down to plpgsql deciding to use a sequential scan, because it can’t really know beforehand if the LIKE-string will be of the form ‘somewhere%’ or ‘%somewhere%’. The first case can make use of a varchar_pattern_ops index I’ve made, while the other one doesn’t have much choice but to use a sequential scan. Is there any way for me to force plpgsql not to use a cached query plan, but instead figure out what’s best based on the LIKE-string that actually get passed to the function?
Regards,
Helge Elvik
On 13 mar 2006, at 11.35, Helge Elvik wrote: > Is there any way for me to force plpgsql not to use a cached query > plan, but instead figure out what’s best based on the LIKE-string > that actually get passed to the function? You can build the query as a string and EXECUTE it. This will force a new plan to be prepared. http://www.postgresql.org/docs/8.1/interactive/plpgsql- statements.html#PLPGSQL-STATEMENTS-EXECUTING-DYN Sincerely, Niklas Johansson