On 11/07/2026 01:44, Trương Hoàng Quân wrote: > I'd appreciate any feedback. If anyone has objections, or can think of a > query pattern where this would break (wrong results, crashes, planner > assertions), please let me know. In the meantime I'll keep expanding the > test coverage for the corner cases I can think of.
Your patch is a big deal for partitioned configurations. But it still has some issues. For example, one direct bug: create table sjo (id int primary key, note text) partition by range (id); create table sjo_1 partition of sjo for values from (0) to (100); insert into sjo values (1,'a'), (2,'b'); select p.id from ONLY sjo p, sjo q where p.id = q.id; This query shouldn't return anything, but I see the output: id ---- 1 2 (2 rows) After fixing this, I think you should add a regression test that checks correctness. Next, in config.sgml for enable_self_join_elimination I see the following: "Takes into consideration only plain tables." — must be updated. Further in the code, I see a stale comment: "We only consider ordinary relations as candidates ..." Performance evidence. It would be nice to see at least a couple of benchmarks: 1. Overhead in case of unsuccessful SJE operation (no unique index present) 2. How much faster (or slower) planning is if SJE has happened. We know it should be a clear profit for the executor, but what does it cost for the planner? -- regards, Andrei Lepikhov, pgEdge
