From: | Joe Conway <mail(at)joeconway(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: [PATCHES] 8.2 features? |
Date: | 2006-07-30 18:21:36 |
Message-ID: | 44CCF8B0.5080406@joeconway.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-docs pgsql-hackers pgsql-patches |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Joe Conway | 2006-07-31 18:57:35 | Re: [HACKERS] 8.2 features? |
Previous Message | Tom Lane | 2006-07-30 17:15:41 | Re: [PATCHES] 8.2 features? |
From | Date | Subject | |
---|---|---|---|
Next Message | Sergey E. Koposov | 2006-07-30 18:33:56 | problem with volatile functions in subselects ? |
Previous Message | Sergey E. Koposov | 2006-07-30 18:13:46 | Re: Do we need multiple forms of the SQL2003 statistics |
From | Date | Subject | |
---|---|---|---|
Next Message | Hannu Krosing | 2006-07-30 18:55:05 | Re: PATCH to allow concurrent VACUUMs to not lock each |
Previous Message | Alvaro Herrera | 2006-07-30 18:11:42 | Re: PATCH to allow concurrent VACUUMs to not lock each |