Re: Performance regression with PostgreSQL 11 and partitioning

On Sat, Jun 9, 2018 at 12:22 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Jun 8, 2018 at 2:10 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>>> I don't understand this complaint.  Before, the code took one
>>> AppendRelInfo, and according to you, it was clear what was supposed to
>>> happen.  Now it takes an array of AppendRelInfos and, according to
>>> you, it's completely unclear.  Yet that seems, to me at least, to be a
>>> straightforward generalization.  If 1 AppendRelInfo is an adequate
>>> specification of one translations, why are N AppendRelInfos not an
>>> adequate specification of N translations?
>>
>> Because the relationships between the transforms are unclear.  Are we
>> supposed to apply those N transformations to the expression in sequence?
>> It doesn't look to me like that's what the code does.  I think --- I might
>> be wrong --- that the code is relying on the transformations to be
>> non-overlapping, that is a change made by any one of them cannot be
>> further affected by another one.  This is, however, undocumented.
>
> OK, I see.  I guess that possible confusion didn't occur to me both
> because I was looking at the code, which I knew wouldn't handle
> overlapping transformations, and also because the intended use was for
> partition-wise join, where the problem can't come up because we're
> translating from the toplevel RTIs for the join to the set of RTIs
> appropriate for one child-join.  But, it's certainly fine to add a
> comment.

That didn't occurred to me as well.

Here's patch with comments and Assertions added to check the
non-overlapping AppendRelInfos. The assertions check that same parent
or child doesn't appear more than once in any of the AppendRelInfos,
neither as a parent nor as a child.

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