Re: Common Table Expressions (WITH RECURSIVE) patch

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Jeff Davis <pgsql(at)j-davis(dot)com>
Cc: David Fetter <david(at)fetter(dot)org>, Tatsuo Ishii <ishii(at)postgresql(dot)org>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Common Table Expressions (WITH RECURSIVE) patch
Date: 2008-09-16 19:43:00
Message-ID: 15726.1221594180@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Jeff Davis <pgsql(at)j-davis(dot)com> writes:
> I think the right approach is to try to complete it so that everyone is
> happy. I will work on this, but unfortunately I don't have a lot of time
> right now, so I can't make any promises.

I think there are two significant bits there:

* Fixing the parsetree representation so that the distinction between
a CTE and an RTE that references the CTE is preserved.

* Implementing some kind of "multiple readout tuplestore" to permit
multiple RTEs to scan a CTE plan without causing any row to be
evaluated more than once.

The first of these seems relatively straightforward: the WITH clause
has to be preserved explicitly in the Query representation, and RTEs
for CTEs should just carry indexes into the WITH list, not copies of
the subqueries. (Hm, we might need both an index and a levelsup
counter, to deal with nested queries...) This would solve ruleutils'
problem, too.

I haven't thought much about the multiple readout tuplestore though.
Anyone have a clear idea how to do that? In particular, can the
existing tuplestore code be enhanced to do it (without sacrificing
performance in the simple case), or do we need something new?

regards, tom lane

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2008-09-16 19:45:18 Re: [HACKERS] Infrastructure changes for recovery
Previous Message Simon Riggs 2008-09-16 19:32:38 EXEC_BACKEND