Re: Out of date comment in cached_plan_cost

On Mon, Dec 11, 2017 at 3:02 AM, David Rowley
<david(dot)rowley(at)2ndquadrant(dot)com> wrote:
> On 9 December 2017 at 06:05, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> On Thu, Dec 7, 2017 at 3:14 AM, David Rowley
>> <david(dot)rowley(at)2ndquadrant(dot)com> wrote:
>>> The attached is my attempt at putting this right.
>>
>> I don't feel entirely right about the way this seems to treat
>> inheritance and partitioning as two entirely separate features; that's
>> true from a user perspective, more or less, but not internally to the
>> code.
>
> Originally I had it typed out in a way that mentioned something about
> "unless using partition-wise join with partitioned tables", but I felt
> that the partition planning code is in such a state of flux at the
> moment that I feared that comment might get outdated again someday in
> the near future.
>
> I've attached another patch which just loosens the claim that join
> planning situation is never made worse by inheritance children to now
> say it does not "generally" make any worse.
>
>> Of course, this also begs the question of whether we ought to be
>> changing the formula somehow.
>
> Perhaps, but not for this patch. The comment already mentions that the
> code is far from perfect.

I don't see much difference in the old and new wording. The word
"generally" confuses more than clarifying the cases when the planning
cost curves do not change with the number of relations i.e.
partitions. I think if we add following sentence after "situation
worse." "However in case of declarative partitioning, we may plan each
child separately e.g partition-wise join aims at planning join between
matching partitions. In that case, plan cost curve significantly
changes with the number of partition relations.". After writing this I
think I understand what you meant by

> Originally I had it typed out in a way that mentioned something about
> "unless using partition-wise join with partitioned tables", but I felt
> that the partition planning code is in such a state of flux at the
> moment that I feared that comment might get outdated again someday in
> the near future.

--
Best Wishes,
Ashutosh Bapat
EnterpriseDB Corporation
The Postgres Database Company