Skip site navigation (1) Skip section navigation (2)

Re: Common Table Expressions (WITH RECURSIVE) patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Greg Stark <greg(dot)stark(at)enterprisedb(dot)com>
Cc: Jeff Davis <pgsql(at)j-davis(dot)com>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Common Table Expressions (WITH RECURSIVE) patch
Date: 2008-09-30 18:03:14
Message-ID: 21167.1222797794@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Greg Stark <greg(dot)stark(at)enterprisedb(dot)com> writes:
> On 24 Sep 2008, at 02:45, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

pgsql-hackers by date

Next:From: Jonah H. HarrisDate: 2008-09-30 18:33:04
Subject: Re: Block-level CRC checks
Previous:From: Alvaro HerreraDate: 2008-09-30 18:02:09
Subject: Block-level CRC checks

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group