On Tue, Jun 14, 2016 at 12:18 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: > Amit Kapila <amit.kapil...@gmail.com> writes: >> On Mon, Jun 13, 2016 at 9:37 PM, Tom Lane <t...@sss.pgh.pa.us> wrote: >>> ... I got a core dump in the window.sql test: >>> which I think may be another manifestation of the failure-to-apply-proper- >>> pathtarget issue we're looking at in this thread. Or maybe it's just >>> an unjustified assumption in make_partialgroup_input_target that the >>> input path must always have some sortgrouprefs assigned. > >> I don't see this problem after your recent commit >> - 89d53515e53ea080029894939118365b647489b3. Are you still getting it? > > No. I am suspicious that there's still a bug there, ie we're looking at > the wrong pathtarget; but the regression test doesn't actually crash. > That might only be because we don't choose the parallelized path.
OK, so there are quite a number of separate things here: 1. The case originally reported by Thomas Munro still fails. To fix that, we probably need to apply scanjoin_target to each partial path. But we can only do that if it's parallel-safe. It seems like what we want is something like this: (1) During scan/join planning, somehow skip calling generate_gather_paths for the topmost scan/join rel as we do to all the others. (2) If scanjoin_target is not parallel-safe, build a path for the scan/join phase that applies a Gather node to the cheapest path and does projection at the Gather node. Then forget all the partial paths so we can't do any bogus upper planning. (3) If scanjoin_target is parallel-safe, replace the list of partial paths for the topmost scan/join rel with a new list where scanjoin_target has been applied to each one. I haven't tested this so I might be totally off-base about what's actually required here... 2. In https://www.postgresql.org/message-id/15695.1465827...@sss.pgh.pa.us Tom raised the issue that we need some test cases covering this area. 3. In https://www.postgresql.org/message-id/25521.1465837...@sss.pgh.pa.us Tom proposed adding a GUC to set the minimum relation size required for consideration of parallelism. 4. In https://www.postgresql.org/message-id/1597.1465846...@sss.pgh.pa.us Tom raised the question of whether there is a danger that MinMaxAggPath might not be parallel-safe. 5. In https://www.postgresql.org/message-id/20391.1465850...@sss.pgh.pa.us Tom proposed a patch to fix an apparent confusion on my part between subplans and subqueries. 6. In https://www.postgresql.org/message-id/ca+tgmozwjb9eaibj-meeaq913wkkoz4aq7vqncfrdls9wyh...@mail.gmail.com I discussed the need to fix the way consider_parallel is set for upper rels, and in https://www.postgresql.org/message-id/22832.1465854...@sss.pgh.pa.us Tom observed that, once that work is done, we can get rid of the wholePlanParallelSafe flag. I don't think it's remotely realistic to get all of this fixed in time for beta2; I think we'll be lucky if we can get #1 fixed. But we'd better track all of these issues so that we can crank through them later. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
