Re: Views and functions returning sets of records

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Giorgio Valoti <giorgio_v(at)mac(dot)com>
Cc: Andreas Kretschmer <akretschmer(at)spamfence(dot)net>, pgsql-performance(at)postgresql(dot)org
Subject: Re: Views and functions returning sets of records
Date: 2008-03-23 15:28:52
Message-ID: 8000.1206286132@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Giorgio Valoti <giorgio_v(at)mac(dot)com> writes:
> Are there any way to pass some hints to the planner? For example,
> could the IMMUTABLE/STABLE/VOLATILE modifiers be of some help?

Those don't really do anything for set-returning functions at the
moment.

As of 8.3 there is a ROWS attribute for SRFs that can help with one
of the worst problems, namely that the planner has no idea how many
rows a SRF might return. It's simplistic (just an integer constant
estimate) but better than no control at all.

As of CVS HEAD (8.4 to be) there's a capability in the planner to
"inline" SRFs that are single SELECTs in SQL language, which should
pretty much eliminate the performance differential against a comparable
view. Unfortunately 8.4 release is at least a year away, but just
so you know. (I suppose if you were desperate enough to run a privately
modified copy, that patch should drop into 8.3 easily enough.) IIRC
the restrictions for this to happen are
* single SELECT
* function declared to return set
* function NOT declared strict or volatile
* function NOT declared SECURITY DEFINER or given any
local parameter settings
The latter restrictions are needed so that inlining doesn't change
the semantics.

regards, tom lane

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Dennis Bjorklund 2008-03-24 07:21:32 Turn correlated in subquery into join
Previous Message Giorgio Valoti 2008-03-23 09:37:12 Re: Views and functions returning sets of records