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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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 Content-Type Size
cte-1003.patch.gz application/octet-stream 49.8 KB

In response to

Responses

Browse pgsql-hackers by date

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