| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Richard Guo <guofenglinux(at)gmail(dot)com>, Alexandra Wang <alexandra(dot)wang(dot)oss(at)gmail(dot)com>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, "bruce(at)momjian(dot)us" <bruce(at)momjian(dot)us>, lepihov(at)gmail(dot)com |
| Subject: | Re: plan shape work |
| Date: | 2025-09-05 16:00:55 |
| Message-ID: | 1376782.1757088055@sss.pgh.pa.us |
| Views: | Whole Thread | Raw Message | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I was not aware of outer_join_rels, so thank you for pointing it out.
> However, consider this query:
> select 1 from pg_class a inner join pg_class b on a.relfilenode = b.relfilenode;
> Here, we end up with a three-item range table: one for a, one for b,
> and one for the join. But the join is not an outer join, and does not
> appear in root->outer_join_rels. Therefore, I'm not sure we can rely
> on outer_join_rels in this scenario.
Plain (not-outer) joins will never be included in a relid set in the
first place.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Nazir Bilal Yavuz | 2025-09-05 16:22:30 | Re: Differential Code Coverage report for Postgres |
| Previous Message | Robert Haas | 2025-09-05 15:51:07 | Re: plan shape work |