Re: [PATCHES] 8.2 features?

From: Joe Conway <mail(at)joeconway(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Christopher Kings-Lynne <chris(dot)kings-lynne(at)calorieking(dot)com>, "Hackers (PostgreSQL)" <pgsql-hackers(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: [PATCHES] 8.2 features?
Date: 2006-07-20 23:13:34
Message-ID: 44C00E1E.1000405@joeconway.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-docs pgsql-hackers pgsql-patches

Tom Lane wrote:
> Joe Conway <mail(at)joeconway(dot)com> writes:
>>I was actually just looking at that and ended up thinking that it might
>>be better to deal with it one level down in ExecProject (because it is
>>already passing targetlists directly to ExecTargetList).
>
> I'd vote against that, because (a) ExecProject is used by all executor
> node types, and we shouldn't add overhead to all of them for the benefit
> of one; (b) ExecProject doesn't actually have any internal state at the
> moment. To keep track of which targetlist to evaluate next, it would
> not only need some internal state, it would have to be told the current
> "es_direction". This stuff fits much better at the exec node level ---
> again, I'd suggest looking at Append for a comparison.

OK.

> But really the executor part of this is not the hard part; what we need
> to think about first is what's the impact on the Query datastructure
> that the parser/rewriter/planner use.

After a quick look, I think changing Query.targetList is too big an
impact, and probably unneeded given your suggestion below.

One of the problems with the current code is that the targetList in the
"VALUES..." case is being used for two purposes -- 1) to define the
column types, and 2) to hold the actual data. By putting the data into a
new node type, I think the targetList reverts to being just a list of
datatypes as it is with INSERT ... SELECT ...

> I'm still liking the idea of pushing multi-values into a jointree node
> type. Basically this would suggest representing "VALUES ..." as if it
> were "SELECT * FROM VALUES ..." (which I believe is actually legal
> syntax per spec) --- in the general case you'd need to have a Query node
> that has a trivial "col1, col2, col3, ..." targetlist and then the
> multiple values lists are in some kind of jointree entry. But possibly
> this could be short-circuited somehow, at least for INSERT.

I'm liking this too. But when you say "jointree node", are you saying to
model the new node type after NestLoop/MergeJoin/HashJoin nodes? These
are referred to as "join nodes" in ExecInitNode. Or as you mentioned a
couple of times, should this look more like an Append node?

Thanks,

Joe

In response to

Responses

Browse pgsql-docs by date

  From Date Subject
Next Message Tom Lane 2006-07-21 00:46:13 Re: [PATCHES] 8.2 features?
Previous Message Tom Lane 2006-07-20 05:39:31 Re: [PATCHES] 8.2 features?

Browse pgsql-hackers by date

  From Date Subject
Next Message Hiroshi Saito 2006-07-21 00:00:03 Re: pgsql: As a stopgap to get the Windows buildfarm members running again,
Previous Message Neil Conway 2006-07-20 22:51:27 Re: Using EXPLAIN in regressions?

Browse pgsql-patches by date

  From Date Subject
Next Message Tom Lane 2006-07-21 00:46:13 Re: [PATCHES] 8.2 features?
Previous Message Joachim Wieland 2006-07-20 17:28:44 Re: modular pg_regress.sh