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