Re: Removing unneeded self joins
Andrei Lepikhov <lepihov@gmail.com>
Commits
GET /api/v1/messages/:b64id/commits
the thread's linked commits as JSON, with link sources.
API reference →
-
Remove GUC_NOT_IN_SAMPLE from enable_self_join_elimination
- 717d0e8dd945 18.0 landed
-
Put enable_self_join_elimination into postgresql.conf.sample
- c2d329260cd8 18.0 landed
-
Get rid of ojrelid local variable in remove_rel_from_query()
- e167191dc146 18.0 landed
-
Implement Self-Join Elimination
- fc069a3a6319 18.0 cited
-
Revert: Remove useless self-joins
- d1d286d83c0e 17.0 landed
-
Replace lateral references to removed rels in subqueries
- 466979ef031a 17.0 landed
-
Replace relids in lateral subquery parse tree during SJE
- 489072ab7a9e 17.0 landed
-
Forbid SJE with result relation
- 8c441c082797 17.0 landed
-
Fix misuse of RelOptInfo.unique_for_rels cache by SJE
- 30b4955a4668 17.0 landed
-
Replace the relid in some missing fields during SJE
- a7928a57b9f0 17.0 landed
-
Revert 56-bit relfilenode change and follow-up commits.
- a448e49bcbe4 16.0 cited
-
Stabilize timetz test across DST transitions.
- 4a071afbd056 14.0 cited
-
Speed up finding EquivalenceClasses for a given set of rels
- 3373c7155350 13.0 cited
-
Fix mark-and-restore-skipping test case to not be a self-join.
- 24d08f3c0a1f 12.0 landed
On 26/2/2025 13:14, Alexander Korotkov wrote: > On Mon, Feb 24, 2025 at 2:22 PM Andrei Lepikhov <lepihov@gmail.com> wrote: >> On 24/2/2025 11:57, Alexander Korotkov wrote: >>> Could you, please, elaborate more on what you mean by "new technique >>> of query tree reduction"? >> I mean any transformations and optimisations that reduce search space >> for optimisation. Right now, I see the features reduce_unique_semijoins, >> remove_useless_joins, and remove_useless_self_joins. >> In practice, I see at least a join on a foreign key, where some cases >> potentially allow the removal of the JOIN operator. > > Do you mean some generic facility, which generalizes all the > transformations you mentioned? If so, it would be cool. But how > could it look like? I think we may realise what it may look like by attempting to implement more RelOptInfo-removal features. Right now, I have only vague ideas on that subject. Just for reference, there were other discussions on join removal [1 - 5] and some blog posts explaining Oracle techniques in this area - see, for example, [6]. [1] inner join removal https://www.postgresql.org/message-id/flat/AANLkTinS_MlZ2F3Siwgcje--qf5nTJTpuHFnZdcA45bU%40mail.gmail.com [2] Patch to support SEMI and ANTI join removal https://www.postgresql.org/message-id/flat/CAApHDvpCBEfuc5tD%3DvniepAv0pU5m%3Dq%3DfOQZcOdMHeei7OQPgQ%40mail.gmail.com [3] Removing INNER JOINs https://www.postgresql.org/message-id/flat/CAApHDvocUEYdt1uT+DLDPs2xEu=v3qJGT6HeXKonQM4rY_OsSA@mail.gmail.com#CAApHDvocUEYdt1uT+DLDPs2xEu=v3qJGT6HeXKonQM4rY_OsSA@mail.gmail.com [4] WIP Join Removal https://www.postgresql.org/message-id/flat/1220176372.4371.118.camel%40ebony.2ndQuadrant [5] Join Removal/ Vertical Partitioning https://www.postgresql.org/message-id/flat/1214477827.3845.87.camel%40ebony.site [6] Oracle Join Elimination https://oracle-base.com/articles/misc/join-elimination -- regards, Andrei Lepikhov