pg.ddx.io  pgsql-docs@postgresql.org mailing list archive  
help / color / mirror / Atom feed
From: Joe Conway <mail@joeconway.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: pgsql-hackers@postgresql.org
Subject: Re: [PATCHES] 8.2 features?
Date: Sun, 30 Jul 2006 11:21:36 -0700
Message-ID: <44CCF8B0.5080406@joeconway.com> (raw)
In-Reply-To: <26226.1154279741@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>
	<26226.1154279741@sss.pgh.pa.us>

Tom Lane wrote:
> 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.

Sounds good to me.

> 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.)

I'll work on that today.

> * 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.

OK.

Thanks,

Joe




view thread (56+ messages)  latest in thread

Message-ID: <44CCF8B0.5080406@joeconway.com>
Permalink:  ../44CCF8B0.5080406@joeconway.com/
Also on:    postgresql.org/message-id/44CCF8B0.5080406@joeconway.com

 · 

reply

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: mail@joeconway.com, tgl@sss.pgh.pa.us, pgsql-hackers@postgresql.org
  Subject: Re: [PATCHES] 8.2 features?
  In-Reply-To: <44CCF8B0.5080406@joeconway.com>

* 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