Re: Query much slower when run from postgres function

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

In response to

Responses

Browse pgsql-jdbc by date

  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

Browse pgsql-performance by date

  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?