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 harmeeksi...@gmail.com 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
I wrote:
HarmeekSingh Bedi harmeeksi...@gmail.com 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
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*
#
HarmeekSingh Bedi harmeeksi...@gmail.com 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
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
HarmeekSingh Bedi harmeeksi...@gmail.com 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
