To: Joe Conway <mail@joeconway.com>
cc: Christopher Kings-Lynne <chris.kings-lynne@calorieking.com>,
	"Patches (PostgreSQL)" <pgsql-patches@postgresql.org>,
	Andrew Dunstan <andrew@dunslane.net>, Bernd Helmle <mailings@oopsware.de>,
	Peter Eisentraut <peter_e@gmx.net>,
	Susanne Ebrecht <susanne.ebrecht@credativ.de>
Subject: Re: Values list-of-targetlists patch for comments (was Re: [HACKERS]
	8.2 features?)
In-reply-to: <44C4451A.4010906@joeconway.com> 
References: <44B69778.5050104@dunslane.net>
	<50461.84.63.113.55.1152832991.squirrel@pezone.net>
	<ECCAAC0A3182895D3D12B0E8@[172.26.14.247]>
	<44B7ADFC.90205@dunslane.net> <44BC0432.3040509@joeconway.com>
	<44BC661F.80609@joeconway.com> <44BCD06C.3060409@calorieking.com>
	<44BCF1D4.3010807@dunslane.net> <5842.1153246741@sss.pgh.pa.us>
	<44BD8854.9060506@calorieking.com> <15212.1153279954@sss.pgh.pa.us>
	<44BDB2F5.7080003@joeconway.com> <44BEA710.6060700@joeconway.com>
	<23198.1153367887@sss.pgh.pa.us> <44BF0382.2010501@joeconway.com>
	<23454.1153370214@sss.pgh.pa.us> <44BF122F.1080200@joeconway.com>
	<23927.1153373971@sss.pgh.pa.us> <44C00E1E.1000405@joeconway.com>
	<14047.1153442773@sss.pgh.pa.us> <44C4451A.4010906@joeconway.com>
Comments: In-reply-to Joe Conway <mail@joeconway.com>
	message dated "Sun, 23 Jul 2006 20:57:14 -0700"
Date: Mon, 24 Jul 2006 12:12:11 -0400
Message-ID: <11495.1153757531@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>

Joe Conway <mail@joeconway.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