I wrote:
> HarmeekSingh Bedi writes:
>> I did make a fix at least to alleviate this case in the optimizer . But I am
>> going to work on a more general approach of expression pruning based on the
>> lifetime of an expression. Basically each node will either references or
>> generate an expression.
HarmeekSingh Bedi writes:
>1. May be I am mistaken Kindly help me understand a bit more. I do agree
>that passing datums up the node chain helps - but consider the case when
>either Sort or Hash joins spills on disk - large columns that get written
> on
>to the disk will still ca
Hi tom .
Thanks for your input . Appreciate your taking time and responding . Just
some comments.
1. May be I am mistaken Kindly help me understand a bit more. I do agree
that passing datums up the node chain helps - but consider the case when
either Sort or Hash joins spills on disk -
HarmeekSingh Bedi writes:
> Thanks Tom. Here is a example. Just a background of things . I have made
> changes in postgress execution and storage engine to make it a MPP style
> engine - keeping all optimizer intact. Basically take pgress serial plan and
> construct a parallel plan. The query I am
Thanks Tom. Here is a example. Just a background of things . I have made
changes in postgress execution and storage engine to make it a MPP style
engine - keeping all optimizer intact. Basically take pgress serial plan and
construct a parallel plan. The query I am running is below.
*Query*
# expl
HarmeekSingh Bedi writes:
>In a plan where Node 1 is parent {say join) and Node 2 is child
> (say scan) . If node 1 has a expression say foo(column) then scan
> will project 'column' for sure and join will
> evaluate foo(column). Now if the node above join does not need
> column ? how
Hi .
Apology for the bandwith. Did not know who to ask the question . I
was interested in a brief detail on how postgress does expression
pruning between nodes . The basic question is as follows
Scenerio
In a plan where Node 1 is parent {say join) and Node 2 is child
(say scan) . If node 1
