Re: Query with high planning time at version 11.1 compared versions10.5 and 11.0

(2019/01/11 13:46), Amit Langote wrote:
> On 2019/01/10 15:07, Etsuro Fujita wrote:
>> (2019/01/10 10:41), Amit Langote wrote:
>>> That's a loaded meaning and abusing it to mean something else can be
>>> challenged, but we can live with that if properly documented.  Speaking of
>>> which:
>>>
>>>       /* used by partitionwise joins: */
>>>       bool        consider_partitionwise_join;    /* consider
>>> partitionwise join
>>>                                                    * paths? (if partitioned
>>> rel) */
>>>
>>> Maybe, mention here how it will be abused in back-branches for
>>> non-partitioned relations?
>>
>> Will do.
>
> Thank you.

I know we don't yet reach a consensus on what to do in details to 
address this issue, but for the above, how about adding comments like 
this to set_append_rel_size(), instead of the header file:

         /*
          * If we consider partitionwise joins with the parent rel, do 
the same
          * for partitioned child rels.
          *
          * Note: here we abuse the consider_partitionwise_join flag for 
child
          * rels that are not partitioned, to tell try_partitionwise_join()
          * that their targetlists and EC entries have been generated.
          */
         if (rel->consider_partitionwise_join)
             childrel->consider_partitionwise_join = true;

ISTM that that would be more clearer than the header file.

Updated patch attached, which also updated other comments a little bit.

Best regards,
Etsuro Fujita