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
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 |