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

From Robert Haas
Subject Re: a path towards replacing GEQO with something better
Date
Msg-id CA+TgmoZESkC+n_0r15ZSoavb-SpJVo1N7+_30Q5ax6u5WN2iqg@mail.gmail.com
Whole thread Raw
In response to Re: a path towards replacing GEQO with something better  (John Naylor <john.naylor@enterprisedb.com>)
Responses Re: a path towards replacing GEQO with something better
Re: a path towards replacing GEQO with something better
List pgsql-hackers
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?

-- 
Robert Haas
EDB: http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: snapshot too old issues, first around wraparound and then more.
Next
From: Peter Geoghegan
Date:
Subject: Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic