Re: BUG #17564: Planner bug in combination of generate_series(), unnest() and ORDER BY
Richard Guo <guofenglinux@gmail.com>
From: Richard Guo <guofenglinux@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Martijn van Oosterhout <kleptog@gmail.com>, PostgreSQL mailing lists <pgsql-bugs@lists.postgresql.org>
Date: 2022-08-04T01:05:13Z
Lists: pgsql-bugs
On Wed, Aug 3, 2022 at 10:56 PM Tom Lane <tgl@sss.pgh.pa.us> wrote: > Richard Guo <guofenglinux@gmail.com> writes: > > On Tue, Aug 2, 2022 at 4:50 PM Martijn van Oosterhout <kleptog@gmail.com > > > > wrote: > >> Now it's morning I've thought of a way to reproduce it more easily, see > >> the attached script. > > > Thanks for the report! I can reproduce it on HEAD. > > FWIW, this reproduces the bug for me in v13 and v14, but not v15 or HEAD. > While the method to fix the bug seems clear enough, it doesn't seem > like we have a test case that's stable enough to be worth anything > as a regression test. Hmmm... I'm reproducing this bug in HEAD with the repro given by Martijn, but with some additional GUC sets: set enable_hashjoin to off; set enable_mergejoin to off; set enable_indexscan to off; set enable_bitmapscan to off; When building access paths for base rel 'results', we would generate Gather Merge on top of its partial path. The key point to reproduce this bug is how to make this Gather Merge path win in the final plan. Another way to reproduce this bug in HEAD is to manually hack the cost of this Gather Merge path to zero with gdb, so that this bug can be reproduced even with hashjoin. Thanks Richard
Commits
-
Add proper regression test for the recent SRFs-in-pathkeys problem.
- cc116479917b 16.0 landed
- 8d38ccafca93 13.8 landed
- 1a9ac84923b8 14.5 landed
- 11e7d626cee4 15.0 landed
-
Fix incorrect tests for SRFs in relation_can_be_sorted_early().
- da4ed7588132 13.8 landed
- 445b9020c97f 14.5 landed
- 1aa8dad41ffa 16.0 landed
- 14168d57bb91 15.0 landed
-
Optimize order of GROUP BY keys
- db0d67db2401 15.0 cited