| 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:55:39 |
| Message-ID: | AANLkTingJVG2Kn6g2YDjOu7O_2Upmg9VXCh-WthwLej8@mail.gmail.com |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
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?
merlin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Merlin Moncure | 2010-05-25 14:57:42 | Re: Query timing increased from 3s to 55s when used as a function instead of select |
| Previous Message | Joshua Tolley | 2010-05-25 14:27:01 | Re: tunning pgsql 7.3.7 over RHEL 4.0 32 x86 (2.6.9-5ELsmp) |