Re: Common Table Expressions (WITH RECURSIVE) patch - Mailing list pgsql-hackers

From Tom Lane
Subject Re: Common Table Expressions (WITH RECURSIVE) patch
Date
Msg-id 21167.1222797794@sss.pgh.pa.us
Whole thread Raw
In response to Re: Common Table Expressions (WITH RECURSIVE) patch  (Greg Stark <greg.stark@enterprisedb.com>)
Responses Re: Common Table Expressions (WITH RECURSIVE) patch  (Dimitri Fontaine <dfontaine@hi-media.com>)
List pgsql-hackers
Greg Stark <greg.stark@enterprisedb.com> writes:
> On 24 Sep 2008, at 02:45, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The next big
>> thing seems to be to figure out exactly how to do multiple references
>> to CTE outputs, so that we can de-bogotify the planner.

> I've looked and don't seem to still have the source tree where I  
> worked on this. I remember how I made the changes to tuplestore which  
> was mostly mechanical. The trick I think will be in adding a special  
> purpose executor method which passes the call site to the node below.  
> This depends on the observation that if we always memoize results then  
> each call site can only have one active call. That is, we don't need  
> to maintain a full stack tree. 

I looked at the tuplestore code a bit and decided that this actually
doesn't need to be hard at all.  Tuplestore already has a notion of a
write position and an independent read position, and we don't need more
than one write position.  So what I think we should do is add "get read
position" and "set read position" functions to tuplestore.c, and have
each of the reader nodes remember its own read position.  That is,
each reader has to do
set_read_position(tupstore, &local_read_position);tuple = tuplestore_gettuple(tupstore,
...);get_read_position(tupstore,&local_read_position);
 

rather than just tuplestore_gettuple.  The set/get functions will be
cheap enough that this is no big deal.  (Or maybe we should just
provide a wrapper function that does this sequence?)
        regards, tom lane


pgsql-hackers by date:

Previous
From: Alvaro Herrera
Date:
Subject: Block-level CRC checks
Next
From: "Jonah H. Harris"
Date:
Subject: Re: Block-level CRC checks