Re: BUG #15577: Query returns different results when executed multiple times
David Rowley <david.rowley@2ndquadrant.com>
From: David Rowley <david.rowley@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>,
Thomas Munro <thomas.munro@enterprisedb.com>, Bartosz Polnik <bartoszpolnik@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2019-01-10T02:29:12Z
Lists: pgsql-bugs
On Thu, 10 Jan 2019 at 15:06, Robert Haas <robertmhaas@gmail.com> wrote: > As to disallow "this plan shape," both leader participation and the > ability to generate this kind of plan are there because they improve > performance substantially on some queries. I put a heck of a lot of > energy into being able to parallelize only part of a query, and into > allowing for leader participation, and I believe those things make a > real difference. I 100% agree that this shape of plan is useful. I guess though, that whether we keep allowing it or not depends on if a suitable fix appears for the issue. One idea that I've been thinking about is some sort of param context number that we bump during createplan when we encounter a Gather/GatherMerge path and have assign_param_for_var() pay attention to that number when deciding if sharing a parameter is okay. How exactly that context number is calculated and how we pass the value around I've currently no idea, so please consider this very handwavy. -- David Rowley http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services
Commits
-
Avoid sharing PARAM_EXEC slots between different levels of NestLoop.
- 2977a312df71 10.7 landed
- 05eb923eae46 11.2 landed
- 1db5667bac63 12.0 landed
- 4f80974990dc 9.6.12 landed