Re: Fix BUG #17335: Duplicate result rows in Gather node
David Rowley <dgrowleyml@gmail.com>
From: David Rowley <dgrowleyml@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Yura Sokolov <y.sokolov@postgrespro.ru>, PostgreSQL Developers <pgsql-hackers@lists.postgresql.org>
Date: 2022-01-25T21:30:59Z
Lists: pgsql-hackers
On Wed, 26 Jan 2022 at 05:32, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Therefore, what I think could be useful is some very-late-stage
> assertion check (probably in createplan.c) verifying that the
> child of a Gather is parallel-aware. Or maybe the condition
> needs to be more general than that, but anyway the idea is for
> the back end of the planner to verify that we didn't build a
> silly plan.
Yeah, it would be nice to have something like this. I think to do it,
we might need to invent some sort of path traversal function that can
take a custom callback function. The problem is that the parallel
aware path does not need to be directly below the gather/gathermerge.
For example (from select_distinct.out)
Unique
-> Sort
Sort Key: four
-> Gather
Workers Planned: 2
-> HashAggregate
Group Key: four
-> Parallel Seq Scan on tenk1
For this case, the custom callback would check that there's at least 1
parallel_aware subpath below the Gather/GatherMerge.
There's probably some other rules that we could Assert are true. I
think any parallel_aware paths (unless they're scans) must contain
only parallel_aware subpaths. For example, parallel hash join must
have a parallel aware inner and outer.
David
Commits
-
Consider parallel awareness when removing single-child Appends
- 2ccd8fb29d74 12.10 landed
- f8807e7742e5 13.6 landed
- 357ff66153b4 14.2 landed
- f9a74c1498d2 15.0 landed
-
Suppress Append and MergeAppend plan nodes that have a single child.
- 8edd0e79460b 12.0 cited