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

  1. Avoid sharing PARAM_EXEC slots between different levels of NestLoop.