| From: | "Vyacheslav Kalinin" <vka(at)mgcp(dot)com> |
|---|---|
| To: | "Julius Tuskenis" <julius(at)nsoft(dot)lt> |
| Cc: | pgsql-admin(at)postgresql(dot)org |
| Subject: | Re: function executes sql 100 times longer it should |
| Date: | 2008-11-13 15:44:38 |
| Message-ID: | 9b1af80e0811130744o7421d79bue68d58b04167a929@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-admin |
Apparently your problem starts here:
> -> Function Scan on filter_b_preke_matoma (cost=0.00..267.50 rows=5
width=126) (actual time=6.580..11.766 rows=2820 loops=1)
> Filter:
(((prek_pavadinimas)::text ~~* (('%'::text || ($3)::text) || '%'::text)) OR
($3 IS NULL))
Planner expects to see only somewhat 5 rows after function scan with the
filter but get ~3000, which is not a surprise if one looks at your plain SQL
query, corresponding WHERE part:
AND ((prek_pavadinimas ILIKE ('%'||null||'%')) OR null is NULL)
As I mentioned conditions like this get wrapped (to TRUE in your case), so
with plain SQL planner does not even try to estimate ILIKE filter effect.
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Isabella Ghiurea | 2008-11-13 21:10:15 | db restore question/issue |
| Previous Message | Julius Tuskenis | 2008-11-13 13:29:09 | Re: function executes sql 100 times longer it should |