Re: pgstat SRF? - Mailing list pgsql-hackers

From Magnus Hagander
Subject Re: pgstat SRF?
Date
Msg-id 20080421160936.3a72bf6a@mha-laptop
Whole thread Raw
In response to Re: pgstat SRF?  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: pgstat SRF?  (Magnus Hagander <magnus@hagander.net>)
List pgsql-hackers
Tom Lane wrote:
> Magnus Hagander <magnus@hagander.net> writes:
> > While looking over the statistics-for-functions patch
> > (http://archives.postgresql.org/pgsql-patches/2008-03/msg00300.php),
> > I came back to a thought I've had before - why do we keep one
> > function per column for pgstat functions, instead of using a set
> > returning function? Is there some actual reason for this, or is it
> > just legacy from a time when it was (much) harder to write SRFs?
> 
> I think it's so that you can build your own stats views instead of
> being compelled to select the data someone thought was good for you.

You can still do that if it's an SRF. You could even make the SRF take
an optional argument to either return a single value (filtered the same
way the individual functions are) or when this one is set to NULL,
return the whole table. 

It would make the overhead a lot lower in the most common case ("SELECT
* FROM pg_stat_<somethingorother>"), while only adding a little in the
other cases, I think.

Though I'm not sure that overhead is big enough to care about in the
first place, but if you're VIEWs are longish it could be...

//Magnus


pgsql-hackers by date:

Previous
From: Magnus Hagander
Date:
Subject: Re: TODO, FAQs to Wiki?
Next
From: Peter Eisentraut
Date:
Subject: Re: TODO, FAQs to Wiki?