From: | "Helge Elvik" <helge(dot)elvik(at)gispartner(dot)no> |
---|---|
To: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Problem getting plpgsql to choose the right query plan |
Date: | 2006-03-13 10:35:11 |
Message-ID: | BCF3CD4320BEC046BB4ACE37A175D87548EE@gispserver01.GISpartnernew.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Martijn van Oosterhout | 2006-03-13 10:40:28 | Re: ERROR: FULL JOIN is only supported with merge-joinable join conditions |
Previous Message | Erik Ferencz | 2006-03-13 10:08:07 | Case Sensitive problem |