Re: Removing unneeded self joins

Andrei Lepikhov <lepihov@gmail.com>

From: Andrei Lepikhov <lepihov@gmail.com>

To: Alexander Korotkov <aekorotkov@gmail.com>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Cc: Tom Lane <tgl@sss.pgh.pa.us>, Robert Haas <robertmhaas@gmail.com>, Richard Guo <guofenglinux@gmail.com>, Alexander Lakhin <exclusion@gmail.com>, "Gregory Stark (as CFM)" <stark.cfm@gmail.com>, Michał Kłeczek <michal@kleczek.org>, Dean Rasheed <dean.a.rasheed@gmail.com>

Date: 2024-12-23T08:25:32Z

Lists: pgsql-hackers

Commits

Same data as JSON: 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

Attachments

v8-0001-Remove-useless-self-joins.patch (text/x-patch) patch v8-0001

On 12/9/24 13:03, Alexander Korotkov wrote:
> On Sat, Jul 20, 2024 at 2:38 PM Alexander Korotkov <aekorotkov@gmail.com> wrote:
> We may decide to generate not just a walker but most of the logic in
> remove_self_join_rel().  This is probably possible by injecting way
> more meta-information into definitions of structures.  That isn't
> going to be simpler than the current approach.  But it is probably
> less error-prone: one could realize that if you add a new field to the
> structure, it should have a similar pg_node_attr() as surroundings.
> But I am afraid that if we go this way, we may end up with an awkward
> heap of pg_node_attr() to generate the functionality of
> remove_self_join_rel().  Should we better add comments to PlannerInfo
> and other relevant structures saying: if you're going to modify this,
> consider how that affects remove_self_join_rel()?
> 
> Any thoughts?

Observing positive cases caused by the SJE feature, I resumed the work 
and, following Alexander's suggestion, added developer comments on 
checking remove_self_join_rel in case of the PlannerInfo changes.

I see now that it helps apply after pull-up transformations and, 
sometimes, because of clauses derived from EquivalenceClasses (see the 
patch comment for examples). So, it is not only about dumb ORM-generated 
queries.

Also, multiple code changes since the v7 version caused corresponding 
changes in the SJE code on rebase. So, the new version provided in the 
attachment needs a fresh review.

-- 
regards, Andrei Lepikhov