I've posted the patch here:
http://archives.postgresql.org/pgsql-patches/2008-01/msg00123.php
Dean.
_
Get Hotmail on your mobile, text MSN to 63463!
http://mobile.uk.msn.com/pc/mail.aspx
---(end of
Is there any way that I can see what execution plan is being used
internally by the functions?
Not directly, but you can do this:
postgres=# PREPARE p (int4) AS SELECT id FROM foo WHERE lower(name) LIKE
'foo' ORDER BY id OFFSET 0 LIMIT $1;
PREPARE
postgres=# EXPLAIN EXECUTE
Dnia 27-01-2008, N o godzinie 17:29 +, Dean Rasheed pisze:
The CONTEXT is very useful, particularly when functions call other
functions, since it gives the call stack (presumably only for SQL and
PL/pgSQL functions). For top-level queries I would ideally like the
CONTEXT to log the SQL
On Jan 27, 2008 12:29 PM, Dean Rasheed [EMAIL PROTECTED] wrote:
Is there any way that I can see what execution plan is being used
internally by the functions?
Not directly, but you can do this:
postgres=# PREPARE p (int4) AS SELECT id FROM foo WHERE lower(name) LIKE
'foo' ORDER
Hi,
I have been having difficulty with some functions which return sets of
rows. The functions seem to run very slowly, even though the queries
they run execute very quicky if I run them directly from psgl.
Typically these queries are only returning a few hundred rows with my
real data.
I have
Dean Rasheed wrote:
I have been having difficulty with some functions which return sets of
rows. The functions seem to run very slowly, even though the queries
they run execute very quicky if I run them directly from psgl.
Typically these queries are only returning a few hundred rows with my
On Jan 20, 2008 9:34 AM, Heikki Linnakangas [EMAIL PROTECTED] wrote:
Dean Rasheed wrote:
I have been having difficulty with some functions which return sets of
rows. The functions seem to run very slowly, even though the queries
they run execute very quicky if I run them directly from psgl.
Thanks for the replies.
Converting the functions to plpgsql and using EXECUTE works a treat.
On the real data, one of my functions is now over 50x faster :-)
Dean
Date: Sun, 20 Jan 2008 10:25:48 -0500
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Re: [PERFORM] Slow set-returning
Merlin Moncure [EMAIL PROTECTED] writes:
prepared statements have the same problem. IIRC the planner assumes
10%, which will often drop to a seqscan or a bitmap index scan. Some
years back I argued (unsuccessfully) to have the planner guess 100
rows or something like that. Ideally, I think
