To: Giorgio Valoti <giorgio_v@mac.com>
cc: Andreas Kretschmer <akretschmer@spamfence.net>,
	pgsql-performance@postgresql.org
Subject: Re: Views and functions returning sets of records 
In-reply-to: <D49B7437-F5A9-44FC-807F-C8472C059B2B@mac.com> 
References: <6A737ADC-2A11-4A01-8ACE-C439E4297273@mac.com>
	<29705.1206203639@sss.pgh.pa.us>
	<20080322165551.GA19460@KanotixBox>
	<D49B7437-F5A9-44FC-807F-C8472C059B2B@mac.com>
Comments: In-reply-to Giorgio Valoti <giorgio_v@mac.com>
	message dated "Sun, 23 Mar 2008 10:37:12 +0100"
Date: Sun, 23 Mar 2008 11:28:52 -0400
Message-ID: <8000.1206286132@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Giorgio Valoti <giorgio_v@mac.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