Message-ID: <491D7103.7000105@nsoft.lt>
Date: Fri, 14 Nov 2008 14:37:23 +0200
From: Julius Tuskenis <julius@nsoft.lt>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: "pgsql-admin@postgresql.org" <pgsql-admin@postgresql.org>
Subject: Re: function executes sql 100 times longer it should
References: <491AE3F2.601@nsoft.lt>	
	<1226500247.2221.2.camel@lin-it1.eaglepress.local>	
	<491BE279.50702@nsoft.lt>	
	<9b1af80e0811130345o37666c5dob841d93954826357@mail.gmail.com>	
	<491C2BA5.7080401@nsoft.lt>
	<9b1af80e0811130744o7421d79bue68d58b04167a929@mail.gmail.com>
In-Reply-To: <9b1af80e0811130744o7421d79bue68d58b04167a929@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit

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