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" <stark(at)enterprisedb(dot)com>
Cc: "Hitoshi Harada" <umi(dot)tanuki(at)gmail(dot)com>, "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-10-03 19:55:56
Message-ID: 3794.1223063756@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
I've successfully taught the WITH patch to do single evaluation of WITH
queries.  I've also been through all of the planner and executor code
for it and am now feeling pretty happy with the whole thing.  There are
still a small number of loose ends (see XXX in the patch), but I don't
believe any of them represent significant work --- I just left them
undone because they weren't in the way of testing anything else.

One point of interest (at least to Hitoshi-san) is that my first cut
at the multiple-readout tuplestore turned out to be not quite the right
thing.  In the original code, if the read pointer was "at eof" (meaning
the previous gettuple call had returned null), then a puttuple call
would move the read pointer forward over the added tuple, keeping it
"at eof".  This was done because nodeMaterial.c wanted it and no other
callers cared particularly.  I had generalized that to the idea that
*all* read pointers that are "at eof" should get moved; but this turns
out to be a really bad idea, at least for nodeCtescan's usage.  What
seems to be the right thing is for only the "active" read pointer to
be moved forward, with inactive ones dropping out of "at eof" state.
This seems reasonable because the point is to not have to reprocess
a tuple you know you just stuck into the tuplestore --- but the other
readers of the tuplestore won't know that, and need to see the tuple
you added.  But it might be that we need to make the behavior
configurable somehow, if the window-functions patch turns out to
need something different.

Barring surprises in the loose ends, I expect to be able to commit
this in a couple of days.

			regards, tom lane


Attachment: cte-1003.patch.gz
Description: application/octet-stream (49.8 KB)

In response to

Responses

pgsql-hackers by date

Next:From: Robert HaasDate: 2008-10-04 01:39:37
Subject: Re: patch: Add columns via CREATE OR REPLACE VIEW
Previous:From: Alvaro HerreraDate: 2008-10-03 16:56:58
Subject: Re: parallel restore test results

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