(2018/08/15 0:51), Robert Haas wrote:
On Mon, Aug 13, 2018 at 12:32 PM, Etsuro Fujita
<fujita.ets...@lab.ntt.co.jp> wrote:
One thing I noticed might be an improvement is to skip
build_joinrel_partition_info if the given joinrel will be to have
consider_partitionwise_join=false; in the previous patch, that function
created the joinrel's partition info such as part_scheme and part_rels if
the joinrel is considered as partitioned, independently of the flag
consider_partitionwise_join for it, but if that flag is false, we don't
generate PWJ paths for the joinrel, so we would not need to create that
partition info at all. This would not only avoid unnecessary processing in
that function, but also make unnecessary the changes I made to
try_partitionwise_join, generate_partitionwise_join_paths,
apply_scanjoin_target_to_paths, and create_ordinary_grouping_paths. So I
updated the patch that way. Please find attached an updated version of the
patch.
I guess the question is whether there are (or might be in the future)
other dependencies on part_scheme. For example, it looks like
partition pruning uses it. I'm not sure whether partition pruning
supports a plan like:
Append
-> Nested Loop
-> Seq Scan on p1
-> Index Scan on q1
<repeat the above for p2/q2 etc.>
I'm not sure that either, but if a join relation doesn't have
part_scheme set, it means that that relation is considered as
non-partitioned, as in the case when enable_partitionwise_join is off,
so there would be no PWJ paths generated for it, to begin with. So in
that case, ISTM that we don't need to worry about that at least for
partition pruning.
Best regards,
Etsuro Fujita