Re: function executes sql 100 times longer it should
От | Julius Tuskenis |
---|---|
Тема | Re: function executes sql 100 times longer it should |
Дата | |
Msg-id | 491D7103.7000105@nsoft.lt обсуждение исходный текст |
Ответ на | Re: function executes sql 100 times longer it should ("Vyacheslav Kalinin" <vka@mgcp.com>) |
Список | pgsql-admin |
once again - thank you Vyacheslav for your quick answer. I have to ask you one more question - is it possible to make a planer act according to passed parameters, or is the plan predefined on creating the function? Vyacheslav Kalinin rašė: > 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. > > -- Julius Tuskenis Programavimo skyriaus vadovas UAB nSoft mob. +37068233050
В списке pgsql-admin по дате отправления: