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: "A(dot) Kretschmer" <andreas(dot)kretschmer(at)schollglas(dot)com>
To: 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 10:30:26
Message-ID: 20100525103026.GA25341@a-kretschmer.de (view raw or flat)
Thread:
Lists: pgsql-performance
In response to Tyler Hildebrandt :
> We're using a function that when run as a select statement outside of the 
> function takes roughly 1.5s to complete whereas running an identical
> query within a function is taking around 55s to complete.
> 
> select * from fn_medirota_get_staff_leave_summary(6);
> Time: 57375.477 ms

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


*untested*


HTH, Andreas
-- 
Andreas Kretschmer
Kontakt:  Heynitz: 035242/47150,   D1: 0160/7141639 (mehr: -> Header)
GnuPG: 0x31720C99, 1006 CCB4 A326 1D42 6431  2EB0 389D 1DC2 3172 0C99

In response to

Responses

pgsql-performance by date

Next:From: Andres FreundDate: 2010-05-25 10:41:58
Subject: Re: performance of temporary vs. regular tables
Previous:From: Tyler HildebrandtDate: 2010-05-25 09:59:43
Subject: Query timing increased from 3s to 55s when used as a functioninstead of select

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