Re: a path towards replacing GEQO with something better

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: John Naylor <john(dot)naylor(at)enterprisedb(dot)com>
Cc: Robert Haas <robertmhaas(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>
Subject: Re: a path towards replacing GEQO with something better
Date: 2021-06-16 16:53:03
Message-ID: 759478.1623862383@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

John Naylor <john(dot)naylor(at)enterprisedb(dot)com> writes:
> On Wed, Jun 16, 2021 at 12:01 PM Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>> 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.

Yeah, I'm not sure I believe this distinction either. IMV a typical star
schema is going to involve joins of dimension-table ID columns to
*different* referencing columns of the fact table(s), so that you won't
get large equivalence classes.

There certainly are cases where a query produces large equivalence classes
that will lead us to investigate a lot of join paths that we wouldn't have
considered were it not for the EC-deduced join clauses. But I don't
think that scenario has much to do with star schemas.

regards, tom lane

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2021-06-16 17:04:07 Re: snapshot too old issues, first around wraparound and then more.
Previous Message Peter Geoghegan 2021-06-16 16:46:07 Re: pg14b1 stuck in lazy_scan_prune/heap_page_prune of pg_statistic