Обсуждение: Re: [PATCHES] 8.2 features?

Поиск
Список
Период
Сортировка

Re: [PATCHES] 8.2 features?

От
Tom Lane
Дата:
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


Re: [PATCHES] 8.2 features?

От
Joe Conway
Дата:
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



Re: [PATCHES] 8.2 features?

От
Michael Glaesemann
Дата:
On Aug 1, 2006, at 16:15 , Harald Armin Massa wrote:

> As accepting 2006-02-31 as a valid date would require brainwashing  
> at least the entire core team, we should find a "recommended path  
> of date migration from different universes".

Have you checked out the mysql2pgsql[1] or my2postgres projects?  
Perhaps they've included this as part of the conversion process.

Michael Glaesemann
grzm seespotcode net


[1](http://gborg.postgresql.org/project/mysql2psql/projdisplay.php)
[2](http://pgfoundry.org/projects/my2postgres/)