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:
> -> Functio
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))
Thank you Vyacheslav.
your "bit or street magic" worked and now I have Execution Plans for both queries: from function and simple SQL.
I'm not good in reading and interpreting these please advice witch part should I put my attention to?
FUNCTION:
"Unique (cost=290.13..290.15 rows=1 width=
Most likely, you get different plans because the function has to deal with
the parametrized query, hence planner cannot effectively use statistics. For
example conditions like this
WHERE (grup_id=$2 OR $2 is Null)
would prevent planner from use of index (if there is one), while with
literal query t
Hello Sean,
Explain plan might be a good start
Its a good start, but leads to nothing because Explain doesn't go into
the function.
EXPLAIN select * -- prek_id, prek_pavadinimas, ks_kaina, mvnt_trumpinys
from fnk_grupes_prekes(18,42,NULL);
"Function Scan on fnk_grupes_prekes (cost=0.00..2
On Wed, 2008-11-12 at 16:10 +0200, Julius Tuskenis wrote:
> Hello, list.
>
> I have one simple SQL function returning result set that takes around 3
> seconds to execute. But if I execute the Select it executes directly -
> it takes only around 30 ms. Why so big difference?
Probably caching the
Hello, list.
I have one simple SQL function returning result set that takes around 3
seconds to execute. But if I execute the Select it executes directly -
it takes only around 30 ms. Why so big difference? What should I check?
I must also say, that this started this afternoon.
PG: 8.3.3
OS:
