Re: Nested query performance issue

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Glenn Maynard <glennfmaynard(at)gmail(dot)com>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Nested query performance issue
Date: 2009-04-10 13:42:26
Message-ID: 21534.1239370946@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Glenn Maynard <glennfmaynard(at)gmail(dot)com> writes:
> http://www.postgresql.org/docs/8.3/static/xfunc-sql.html says this is
> deprecated (though no deprecation warning is being generated):

>> Currently, functions returning sets can also be called in the select list of a query. For each row that the query generates by itself, the function returning set is invoked, and an output row is generated for each element of the function's result set. Note, however, that this capability is deprecated and might be removed in future releases.

The way to parse that is "we don't like this and we will get rid of it
if we can ever figure out a good substitute". Right now there is no
100% substitute, so it stays. (In fact, 8.4 will extend the feature so
it works in cases that don't work today, like for PL functions.)

There are, however, good reasons not to like it, such as the rather
questionable behavior if there's more than one SRF in the same select
list. Don't complain if you run into that wart.

regards, tom lane

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message Tom Lane 2009-04-10 13:50:37 Re: Shouldn't the planner have a higher cost for reverse index scans?
Previous Message Ognjen Blagojevic 2009-04-10 09:47:16 Postgres 8.x on Windows Server in production