Re: a path towards replacing GEQO with something better - Mailing list pgsql-hackers

From John Naylor
Subject Re: a path towards replacing GEQO with something better
Date
Msg-id CAFBsxsFZgRxJEbJsbRFVDis6bQFL8GSEHjZdC+eLkKS8r5116A@mail.gmail.com
Whole thread Raw
In response to Re: a path towards replacing GEQO with something better  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: a path towards replacing GEQO with something better  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers


On Wed, Jun 16, 2021 at 12:01 PM Robert Haas <robertmhaas@gmail.com> wrote:
>
> On Tue, Jun 15, 2021 at 2:16 PM John Naylor
> <john.naylor@enterprisedb.com> wrote:
> > > I don't quite understand the difference between the "chain" case and
> > > the "star" case. Can you show sample queries for each one? e.g. SELECT
> > > ... FROM a_1, a_2, ..., a_n WHERE <something>?
> >
> > SELECT  *
> > FROM    tab1, tab2, tab3, tab4
> > WHERE   tab1.col = tab2.col AND
> >     tab2.col = tab3.col AND
> >     tab3.col = tab4.col
> >
> > SELECT  *
> > FROM    tab1, tab2, tab3, tab4
> > WHERE   tab1.col = tab2.col AND
> >     tab1.col = tab3.col AND
> >     tab1.col = tab4.col
>
> I feel like these are completely equivalent. Either way, the planner
> is going to deduce that all the ".col" columns are equal to each other
> via the equivalence class machinery, and then the subsequent planning
> will be absolutely identical. Or am I missing something?

I believe the intention of the example is that ".col" is a place holder for some column (all different). Otherwise, with enough ECs it would result in an even bigger set of joinrels than what we see here. If ECs don't actually cause additional joinrels to be created, then I'm missing something fundamental.

--
John Naylor
EDB: http://www.enterprisedb.com

pgsql-hackers by date:

Previous
From: Yugo NAGATA
Date:
Subject: Re: Avoid stuck of pbgench due to skipped transactions
Next
From: Tom Lane
Date:
Subject: Allowing regular identifiers in isolationtester scripts