On Thu, Aug 16, 2018 at 12:36 PM, Alvaro Herrera <alvhe...@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