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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs pgsql-hackers pgsql-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

Browse pgsql-docs by date

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

Browse pgsql-hackers by date

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

Browse pgsql-patches by date

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