From: | Richard Huxton <dev(at)archonet(dot)com> |
---|---|
To: | Scott Schulthess <scott(at)topozone(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Stored Procedure Speed |
Date: | 2007-04-25 14:46:48 |
Message-ID: | 462F69D8.3080601@archonet.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Scott Schulthess wrote:
> Hey Ya'll,
>
> I'm a little puzzled by the speed of the stored procedures I am writing.
>
> Here is the query alone in pgAdmin
>
> select distinct featuretype from gnis_placenames where state='CT'
> TIME: 312+16ms
>
>
>
> Here is a stored procedure
>
> create or replace function getfeaturetypes(text) returns setof text as
> $$
> select distinct featuretype from gnis_placenames where state=$1;
> $$ language sql;
>
> TIME: 2391+15ms
Basically, the planner has more information with the hard-coded example.
It should know enough to come up with different plans for 'CT' and XX'.
Functions (and this varies per-language, but plpgsql is the usual
culprit) cache their query-plans, so you end up with "one size fits all".
You can see what plan it comes up with by using PREPARE ... <query>
followed by EXPLAIN EXECUTE ...
I must say I thought recent versions of PG delayed planning the query
until first call though.
--
Richard Huxton
Archonet Ltd
From | Date | Subject | |
---|---|---|---|
Next Message | A. Kretschmer | 2007-04-25 14:48:49 | Re: Kill a Long Running Query |
Previous Message | Simon Riggs | 2007-04-25 14:42:33 | Re: [DOCS] Incrementally Updated Backups: Docs Clarification |