On Thu, Aug 16, 2018 at 12:36 PM, Alvaro Herrera
<alvherre@2ndquadrant.com> wrote:
> I have to admit I have a hard time understanding this stuff. I don't
> know what a "scan/join target" is (or scan/join relation for that
> matter) ... and this "tlist relation" thing is an entirely new concept
> to me.
Well, I invented the "tlist relation" concept, and it never actually
got committed, so it's not surprising that it's new to you.
The point is that if you do something like SELECT a.x + b.y FROM x, y
WHERE <stuff>, the planner will initially produce a plan that emits
a.x and b.y. But that's not actually what we want to produce: we want
to compute the expression a.x + b.y. So that expression is the
scan/join target. After getting the initial plan that produces a.x
and b.y as separate columns, we perform surgery on that plan to make
it return the computed expression instead.
If x and y are partitioned and the join is partition-wise, it's better
to perform this transformation recursively, getting each child-join to
return a.x + b.y; the alternative is for each child-join to return a.x
and b.y as a separate columns and then perform the projection at the
top level.
> So,
> 1. I'm not sure that partition pruning devs are on the hook for
> producing a test case for the problem originally reported,
> since we're clearly dealing with a wacko plan,
> 2. I wonder if this should be considered an open item related to commit
> 11cf92f6e2e1 instead of partprune.
>
> The other option is to ignore this whole affair, mark this as solved in
> the open items list, and move on.
I don't know whether there's actually a defect here any more. I was
trying to dispel some perceived confusion on the part of David and Tom
about what this code was trying to accomplish, but the fact that the
code caused some confusion does not necessarily mean that there's
anything wrong with it. On the other hand, perhaps it does have
functional deficiencies, or perhaps the comments need work. Or maybe
this code is fine taken in isolation but there are still problems in
how it interacts with partition pruning. Let's start by deciding what
we think the problems are, and then we can decide who should fix them.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company