Re: Removing unneeded self joins

Andres Freund <andres@anarazel.de>

From: Andres Freund <andres@anarazel.de>

To: Tom Lane <tgl@sss.pgh.pa.us>

Cc: Thomas Munro <thomas.munro@enterprisedb.com>, Alexander Kuzmenkov <a.kuzmenkov@postgrespro.ru>, PostgreSQL-development <pgsql-hackers@postgresql.org>

Date: 2018-05-16T22:44:50Z

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

On 2018-05-16 18:37:11 -0400, Tom Lane wrote:
> Thomas Munro <thomas.munro@enterprisedb.com> writes:
> > IIUC in DB2 (the clear winner at join elimination in the article you
> > mentioned), you get these sorts of things by default (optimisation
> > level 5 includes it), but not if you SET CURRENT QUERY OPTIMIZATION =
> > 3 as many articles recommend for OLTP work.  I think it's interesting
> > that they provide that knob rather than something automatic, and
> > interesting that there is one linear knob to classify your workload
> > rather than N knobs for N optimisations.
> 
> There's a lot to be said for that type of approach, as opposed to trying
> to drive it off some necessarily-very-inexact preliminary estimate of
> query cost.  For example, the mere fact that you're joining giant tables
> doesn't in itself suggest that extra efforts in query optimization will be
> repaid.  (If anything, it seems more likely that the user would've avoided
> silliness like useless self-joins in such a case.)

For prepared statements we could also start making more expensive
optimizations after the first execution, when we know how long the query
took / how expensive it was (also, if we had a plan cache...).

Greetings,

Andres Freund