Re: Performance regression with PostgreSQL 11 and partitioning

Tom Lane <tgl@sss.pgh.pa.us>

From: Tom Lane <tgl@sss.pgh.pa.us>
To: Robert Haas <robertmhaas@gmail.com>
Cc: David Rowley <david.rowley@2ndquadrant.com>, Ashutosh Bapat <ashutosh.bapat@enterprisedb.com>, Amit Langote <amitlangote09@gmail.com>, Thomas Reiss <thomas.reiss@dalibo.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2018-06-08T18:10:09Z
Lists: pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Fri, Jun 8, 2018 at 12:56 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> The pre-v11 incarnation of those functions took a single AppendRelInfo,
>> specifying an exact translation from one parent relid to one child
>> relid.  The fundamental problem I've got with the current code, entirely
>> independently of any performance issues, is that it's completely unclear
>> -- or at least undocumented -- which translation(s) are supposed to occur.

> 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.

			regards, tom lane


Commits

  1. Fix typo in comment

  2. Allow direct lookups of AppendRelInfo by child relid

  3. Teach adjust_appendrel_attrs(_multilevel) to do multiple translations.