Re: Removing unneeded self joins

Alexander Korotkov <aekorotkov@gmail.com>

From: Alexander Korotkov <aekorotkov@gmail.com>

To: Andrei Lepikhov <a.lepikhov@postgrespro.ru>

Cc: zyu@yugabyte.com, "Gregory Stark (as CFM)" <stark.cfm@gmail.com>, Michał Kłeczek <michal@kleczek.org>, PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>

Date: 2023-10-21T22:01:49Z

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

0001-Remove-useless-self-joins-v46.patch (application/octet-stream) patch v46-0001

On Thu, Oct 19, 2023 at 6:16 AM Andrei Lepikhov
<a.lepikhov@postgrespro.ru> wrote:
> On 19/10/2023 01:50, Alexander Korotkov wrote:
> > This query took 3778.432 ms with self-join removal disabled, and
> > 3756.009 ms with self-join removal enabled.  So, no measurable
> > overhead.  Similar to the higher number of joins.  Can you imagine
> > some extreme case when self-join removal could introduce significant
> > overhead in comparison with other optimizer parts?  If not, should we
> > remove self_join_search_limit GUC?
> Thanks,
> It was Zhihong Yu who worried about that case [1]. And my purpose was to
> show a method to avoid such a problem if it would be needed.
> I guess the main idea here is that we have a lot of self-joins, but only
> few of them (or no one) can be removed.
> I can't imagine a practical situation when we can be stuck in the
> problems here. So, I vote to remove this GUC.

I've removed the self_join_search_limit.  Anyway there is
enable_self_join_removal if the self join removal algorithm causes any
problems.  I also did some grammar corrections for the comments.  I
think the patch is getting to the committable shape.  I noticed some
failures on commitfest.cputube.org.  I'd like to check how this
version will pass it.

------
Regards,
Alexander Korotkov