From: Tom Lane <tgl@sss.pgh.pa.us>
To: Joe Conway <mail@joeconway.com>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [PATCHES] 8.2 features?
Date: Sun, 30 Jul 2006 13:15:41 -0400
Message-ID: <26226.1154279741@sss.pgh.pa.us> (raw)
In-Reply-To: <21320.1154222840@sss.pgh.pa.us>
References: <200607281947.k6SJlOI02533@momjian.us>
<473.1154116455@sss.pgh.pa.us>
<44CA76A9.8070101@joeconway.com>
<44CB051D.6090609@joeconway.com>
<21320.1154222840@sss.pgh.pa.us>
I wrote:
> I still dislike the way you're doing things in the executor though.
> I don't see the point of using the execScan.c machinery; most of the
> time that'll be useless overhead. As I said before, I think the right
> direction here is to split Result into two single-purpose node types
> and make the non-filter version capable of taking a list of targetlists.
After more thought I've reconsidered this. The "ValuesScan" node is
still redundant with Result's non-filter case, but we should probably
get rid of the latter not the former. The reason is that in the general
case of VALUES-in-FROM, we do need all the generality of execScan.
Consider
SELECT x,y,x+y
FROM (VALUES (1,2),(3,4),...) AS foo(x,y)
WHERE x < y;
which AFAICS is perfectly legal SQL. We need a qual condition for the
WHERE and a projection step to form the x+y result. We could make a
non-filtering Result clause do all that but it'd really be reinventing
the execScan wheel.
So what I'm currently thinking is
1. Implement ValuesScan.
2. Convert all existing uses of Result without a child node into
ValuesScan.
3. Rename Result to Filter and rip out whatever code is only used for
the no-child-node case.
Steps 2 and 3 are just in the nature of housekeeping and can wait till
after the VALUES feature is in.
As far as avoiding overhead goes, here's what I'm thinking:
* The Values RTE node should contain a list of lists of bare
expressions, without TargetEntry decoration (you probably do not
need ResTarget in the raw parse tree for VALUES, either).
* The ValuesScan plan node will just reference this list-of-lists
(avoiding making a copy). It will need to contain a targetlist
because all plan nodes do, but the base version of that will just
be a trivial "Var 1", "Var 2", etc. (The planner might replace that
with a nontrivial targetlist in cases such as the example above.)
* At runtime, ValuesScan evaluates each sublist of expressions and
stores the results into a virtual tuple slot which is returned as
the "scan tuple" to execScan. If the targetlist is nontrivial then
it is evaluated with this tuple as input. If the targetlist is
a trivial Var list then the existing "physical tuple" optimization
kicks in and execScan will just return the scan tuple unmodified.
So for INSERT ... VALUES, the execScan layer will cost us nothing
in memory space and not much in execution time.
There are still some things I don't like about the way you did
ValuesScan but I'll work on improving that.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-docs@postgresql.org
Cc: tgl@sss.pgh.pa.us, mail@joeconway.com, pgsql-hackers@postgresql.org
Subject: Re: [PATCHES] 8.2 features?
In-Reply-To: <26226.1154279741@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox