"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
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-returni
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 fr
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
real
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 h