(2018/08/15 0:51), Robert Haas wrote:
> On Mon, Aug 13, 2018 at 12:32 PM, Etsuro Fujita
> <fujita.etsuro@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