Re: Performance regression with PostgreSQL 11 and partitioning

On Fri, Jun 8, 2018 at 12:56 AM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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?

(On another note, I don't have a strong what should be done about the
fact that all AppendRelInfos are stored in a flat list or whether it
should be done in v11 or v12, but I completely agree with the idea
that something should be done about it at some point. I'm sure it's
possible to design a data structure that is less efficient to search
than a singly-linked list, but you'd probably have to be explicitly
aiming for that goal.)

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company