Re: WITH RECUSIVE patches 0723

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: "Tatsuo Ishii" <ishii(at)postgresql(dot)org>, andrew(at)tao11(dot)riddles(dot)org(dot)uk, pgsql-hackers(at)postgresql(dot)org
Subject: Re: WITH RECUSIVE patches 0723
Date: 2008-07-28 16:44:24
Message-ID: 22969.1217263464@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-patches

Gregory Stark <stark(at)enterprisedb(dot)com> writes:
> "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us> writes:
>> This isn't going to be a particularly simple fix :-(. The basic
>> implementation clearly ought to be to dump the result of the subquery
>> into a tuplestore and then have the upper level read out from that.
>> However, we don't have any infrastructure for having multiple
>> upper-level RTEs reference the same tuplestore.

> Uhm, indeed, isn't that the whole point of the work needed to make recursive
> queries work?

No, I don't think so. The present patch (so far as I've gathered what
it can do, in the absence of any documentation) knows how to feed back
tuples collected at an upper level to a scan node at a lower level,
which is needed to implement recursion. However, if you do

WITH RECURSIVE foo AS (...) SELECT ... FROM foo a, foo b WHERE

then you will still get two independent evaluations of duplicate
querytrees. Which is at least a performance bug, and if there are
any volatile functions inside foo I claim it's a spec violation too.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Stephen R. van den Berg 2008-07-28 16:45:41 Re: Protocol 3, Execute, maxrows to return, impact?
Previous Message Gregory Stark 2008-07-28 16:33:29 Re: WITH RECUSIVE patches 0723

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2008-07-28 17:06:53 Re: WITH RECUSIVE patches 0723
Previous Message Gregory Stark 2008-07-28 16:33:29 Re: WITH RECUSIVE patches 0723