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

Re: Values list-of-targetlists patch for comments (was Re: [HACKERS] 8.2 features?)

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Joe Conway <mail(at)joeconway(dot)com>
Cc: Christopher Kings-Lynne <chris(dot)kings-lynne(at)calorieking(dot)com>, "Patches (PostgreSQL)" <pgsql-patches(at)postgresql(dot)org>, Andrew Dunstan <andrew(at)dunslane(dot)net>, Bernd Helmle <mailings(at)oopsware(dot)de>, Peter Eisentraut <peter_e(at)gmx(dot)net>, Susanne Ebrecht <susanne(dot)ebrecht(at)credativ(dot)de>
Subject: Re: Values list-of-targetlists patch for comments (was Re: [HACKERS] 8.2 features?)
Date: 2006-07-24 16:12:11
Message-ID: 11495.1153757531@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-docspgsql-hackerspgsql-patches
Joe Conway <mail(at)joeconway(dot)com> writes:
> Tom Lane wrote:
>> There are basically two ways you could go about this:
>> 1. Make a new jointree leaf node type to represent a VALUES construct,
>> and dangle the list of lists of expressions off that.
>> 2. Make a new RangeTblEntry type to represent a VALUES construct, and
>> just put a RangeTblRef to it into the jointree.  The expressions
>> dangle off the RangeTblEntry.

You seem to have done *both*, which is certainly not what I had in mind.
I'd drop the RangeTblEntry changes, I think.

Shoving all the tuples into a tuplestore is not doing anything for you
from a performance point of view.  I was thinking more of evaluating the
targetlists on-the-fly.  Basically what I foresaw as the executor
mechanism was something like a Result node, except with a list of
targetlists instead of just one, and part of its runtime state would be
an index saying which one to evaluate next.  (The update logic for the
index would be just like Append's logic for which subplan to eval next.)

Result as it currently stands is a pretty queer beast because it can
have a child plan or not.  I'm tempted to suggest splitting it into
two node types, perhaps call the one with a child "Filter" and reserve
the name "Result" for the one with no child.  The reason for doing this
in this context is that we could just make the no-child case be
multi-targetlist-capable (rather than having separate nearly identical
node types with single and multi tlists).  AFAICS multi tlists don't
make any sense for the filter-a-child-plan scenario, so that's why I
want to push that case off to a different node type.

			regards, tom lane

In response to

Responses

pgsql-docs by date

Next:From: Joe ConwayDate: 2006-07-24 16:32:37
Subject: Re: Values list-of-targetlists patch for comments (was Re:
Previous:From: Joe ConwayDate: 2006-07-24 06:22:14
Subject: Re: Values list-of-targetlists patch for comments (was Re:

pgsql-hackers by date

Next:From: Joshua D. DrakeDate: 2006-07-24 16:23:08
Subject: Re: plPHP and plRuby
Previous:From: Florian G. PflugDate: 2006-07-24 16:07:18
Subject: Re: UPDATE/DELETE XXX WHERE CURRENT OF cursor_name

pgsql-patches by date

Next:From: Joe ConwayDate: 2006-07-24 16:32:37
Subject: Re: Values list-of-targetlists patch for comments (was Re:
Previous:From: Sergey E. KoposovDate: 2006-07-24 15:10:03
Subject: Re: patch implementing the multi-argument aggregates (SOC

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