From: A. Kretschmer <andreas.kretschmer@schollglas.com>
To: pgsql-performance@postgresql.org
Subject: Re: Query timing increased from 3s to 55s when used as a function instead of select
Date: Tue, 25 May 2010 12:30:26 +0200
Message-ID: <20100525103026.GA25341@a-kretschmer.de> (raw)
In-Reply-To: <20100525095943.GA18600@campbell-lange.net>
References: <20100525095943.GA18600@campbell-lange.net>
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
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: andreas.kretschmer@schollglas.com
Subject: Re: Query timing increased from 3s to 55s when used as a function instead of select
In-Reply-To: <20100525103026.GA25341@a-kretschmer.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox