Re: cursors as table sources

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Michael Fuhr <mike(at)fuhr(dot)org>
Cc: Peter Filipov <pfilipov(at)netissat(dot)bg>, pgsql-general(at)postgresql(dot)org
Subject: Re: cursors as table sources
Date: 2006-01-11 18:38:58
Message-ID: 20434.1137004738@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Michael Fuhr <mike(at)fuhr(dot)org> writes:
> ... However, you could
> write a set-returning function that takes a refcursor argument and
> iterates through the cursor, returning each row, and use that
> function in the FROM clause. Whether that's a good idea or not is
> something I haven't given much thought to.

From a performance point of view, at least, it's practically guaranteed
not to be a good idea. By hiding part of the query from the optimizer,
the SRF would prevent any meaningful join optimization from happening.
This applies whether the SRF is reading a cursor or just executing the
query directly.

For the same reason, I can't get very excited about the idea of allowing
a cursor reference in FROM. The cursor is already planned and there
would be no opportunity to alter its plan based on the join context.

I have some recollection that the cursor-in-FROM idea has come up before
and was shot down on yet other grounds than that. Try searching the
archives ...

regards, tom lane

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Will Glynn 2006-01-11 18:41:31 Re: cursors as table sources
Previous Message Michael Fuhr 2006-01-11 18:24:30 Re: cursors as table sources