Re: Problem about postponing gathering partial paths for topmost scan/join rel
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Antonin Houska <ah@cybertec.at>
Cc: Richard Guo <guofenglinux@gmail.com>,
PostgreSQL-development <pgsql-hackers@postgresql.org>
Date: 2022-07-30T17:15:04Z
Lists: pgsql-hackers
Antonin Houska <ah@cybertec.at> writes: > I'm going to set the CF entry to "ready for committer'". I pushed this with some editorialization: * Grepping found another caller of generate_useful_gather_paths with the exact same bug, in geqo_eval.c. (A wise man once said that the most powerful bug-finding heuristic he knew was "where else did we make this same mistake?") * I thought it best to make set_rel_pathlist() use an identically- worded test for the equivalent purpose for baserels. It's not actively broken, but examining bms_membership seems confusingly complicated, and I doubt it's faster than bms_equal either. * I omitted the test case because I didn't think it would buy us anything. It failed to detect the GEQO variant of the bug, and it would fail to detect the most likely future way of breaking this, which is that I forget to change these instances of all_baserels next time I rebase [1]. regards, tom lane [1] https://commitfest.postgresql.org/39/3755/
Commits
-
Fix incorrect is-this-the-topmost-join tests in parallel planning.
- d8e34fa7a18f 16.0 landed
- a3699c599ced 15.0 landed
-
Postpone generate_gather_paths for topmost scan/join rel.
- 3f90ec8597c3 11.0 cited