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

Re: Writeable CTEs and empty relations

From: Marko Tiikkaja <marko(dot)tiikkaja(at)cs(dot)helsinki(dot)fi>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Writeable CTEs and empty relations
Date: 2010-02-10 23:25:22
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
On 2010-02-11 00:50 +0200, Marko Tiikkaja wrote:
> On 2010-02-10 23:57 +0200, Tom Lane wrote:
>> Robert Haas <robertmhaas(at)gmail(dot)com> writes:
>>> If the executor has buried in it the assumption that the snapshot
>>> can't change after startup, then does that mean that we need to start
>>> up and shut down the executor for each subquery?
>> Yes, I think so.  That's the way it's always worked in the past;
>> see for example PortalRunMulti() and ProcessQuery().  I think trying
>> to change that is a high-risk, low-reward activity.
>> This probably means that the planner output for queries involving
>> writeable CTEs has to be a separate PlannedStmt per such CTE.
> I'm looking at this, but I can't think of any good way of associating
> the tuplestores from PortalRunMulti() with the correct CTEs.  Any ideas?

Ok, what about the following:
  - after planning the original query, standard_planner() goes through
    the list of top-level CTEs and assigns a running number for each of
    the DML WITHs, in the order they will be executed and returns a
    list of PlannedStmts.  all necessary statements wi have a flag
    signaling that the result should be stored in a tuplestore.
  - the portal keeps the list of tuplestores around and passes that
    list to every query through PlannedStmt.  it keeps on executing
    the statements until it finds a PlannedStmt that doesn't want its
    results stored anywhere and then frees the list of tuplestores

Does this sound reasonable?  And more importantly, am I going to be
wasting my time implementing this?  The 15th isn't that far away..

Marko Tiikkaja

In response to


pgsql-hackers by date

Next:From: Joachim WielandDate: 2010-02-10 23:52:18
Subject: Re: Listen / Notify - what to do when the queue is full
Previous:From: Kurt HarrimanDate: 2010-02-10 23:04:06
Subject: Re: Patch: Remove gcc dependency in definition of inline functions

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