On Sat, 31 Dec 2022 at 02:32, Tom Lane <t...@sss.pgh.pa.us> wrote: > > I wrote: > > Richard Guo <guofengli...@gmail.com> writes: > >> While we are here, I wonder if we can do the same trick for > >> distinctClause, to cope with cases like > >> select distinct a.x, b.y from a, b where a.x = b.y; > > > We do that already, no? > > Oh, wait, I see what you mean: we are smart in code paths that rely > on distinct_pathkeys, but not in the hash-based code paths. Right, > that can be fixed the same way. 0001 attached is the same as before, > 0002 adds similar logic for the distinctClause. > > The plan change in expected/pg_trgm.out is surprising at first > glance, but I believe it's correct: the item that is being > dropped is a parameterless STABLE function, so its value is not > supposed to change for the duration of the scan.
The patch does not apply on top of HEAD as in [1], please post a rebased patch: === Applying patches on top of PostgreSQL commit ID ff23b592ad6621563d3128b26860bcb41daf9542 === === applying patch ./v3-0002-remove-redundant-DISTINCT.patch .... Hunk #4 FAILED at 4704. .... 1 out of 10 hunks FAILED -- saving rejects to file src/backend/optimizer/plan/planner.c.rej [1] - http://cfbot.cputube.org/patch_41_4083.log Regards, Vignesh