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
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 |