Skip site navigation (1) Skip section navigation (2)

Re: Query timing increased from 3s to 55s when used as a function instead of select

From: Merlin Moncure <mmoncure(at)gmail(dot)com>
To: Tyler Hildebrandt <tyler(at)campbell-lange(dot)net>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Query timing increased from 3s to 55s when used as a function instead of select
Date: 2010-05-25 14:57:42
Message-ID: AANLkTilo7ySxA-Z47lF6jMdgzM7yv3s25-sYTiPWNwyl@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
On Tue, May 25, 2010 at 10:55 AM, Merlin Moncure <mmoncure(at)gmail(dot)com> wrote:
> On Tue, May 25, 2010 at 9:41 AM, Tyler Hildebrandt
> <tyler(at)campbell-lange(dot)net> wrote:
>>> I think, your problem is here:
>>>
>>> SELECT INTO current_user * FROM
>>> fn_medirota_validate_rota_master(in_currentuser);
>>>
>>>
>>> The planner has no knowledge about how many rows this functions returns
>>> if he don't know the actual parameter. Because of this, this query
>>> enforce a seq-scan. Try to rewrite that to something like:
>>>
>>> execute 'select * from fn_medirota_validate_rota_master(' ||
>>> in_currentuser' || ')' into current_user
>>>
>>
>> Thanks for your response.  This doesn't seem to solve our issue, unfortunately.
>>
>> As a side to that, we have the fn_medirota_validate_rota_master calls in a
>> large amount of our other functions that are running very well.
>
> any chance of seeing the function source?

oops! I missed it :-).  looking at your function, what version of
postgres? have you experimented w/return query?

merlin

In response to

pgsql-performance by date

Next:From: Jorge MonteroDate: 2010-05-25 16:18:11
Subject: Re: Query timing increased from 3s to 55s when usedas a function instead of select
Previous:From: Merlin MoncureDate: 2010-05-25 14:55:39
Subject: Re: Query timing increased from 3s to 55s when used as a function instead of select

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group