From: | fche(at)redhat(dot)com (Frank Ch(dot) Eigler) |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Mario Splivalo <mario(dot)splivalo(at)megafon(dot)hr>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Query much slower when run from postgres function |
Date: | 2009-03-10 14:40:51 |
Message-ID: | y0mr615785o.fsf@ton.toronto.redhat.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-jdbc pgsql-performance |
Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
> Mario Splivalo <mario(dot)splivalo(at)megafon(dot)hr> writes:
>> Now I'm confused, why is 'sql' function much slower than 'direct' SELECT?
>
> Usually the reason for this is that the planner chooses a different plan
> when it has knowledge of the particular value you are searching for than
> when it does not. I suppose 'service_id' has a very skewed distribution
> and you are looking for an uncommon value?
For a prepared statement, could the planner produce *several* plans,
if it guesses great sensitivity to the parameter values? Then it
could choose amongst them at run time.
- FChE
From | Date | Subject | |
---|---|---|---|
Next Message | Kris Jurka | 2009-03-10 16:55:24 | Re: [PERFORM] Query much slower when run from postgres function |
Previous Message | Dickson S. Guedes | 2009-03-10 12:00:08 | Re: Renaming sequence auto generated by SERIAL type don't update pg_attrdef |
From | Date | Subject | |
---|---|---|---|
Next Message | henk de wit | 2009-03-10 14:57:03 | Re: When does sequential performance matter in PG? |
Previous Message | Matthew Wakeling | 2009-03-10 14:28:07 | Re: When does sequential performance matter in PG? |