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>, Aleksander Alekseev <aleksander(at)timescale(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Fix bogus Asserts in calc_non_nestloop_required_outer |
Date: | 2024-01-06 21:08:57 |
Message-ID: | 1354294.1704575337@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Fri, Jan 5, 2024 at 4:36 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>> I don't think I believe this code change, let alone any of the
>> explanations for it. The point of these Asserts is to be sure that
>> we don't form an alleged parameterization set that includes any rels
>> that are included in the new join, because that would be obviously
>> wrong. They do check that as they stand. I'm not sure what invariant
>> the proposed revision would be enforcing.
> Well, this explanation made sense to me:
> https://www.postgresql.org/message-id/CAMbWs4-%2BGs0HJ9ouBUb%3DqwHsGCXxG%2B92eJzLOpCkedvgtOWQ%3DQ%40mail.gmail.com
The argument for the patch as proposed is that we should make the
mergejoin and hashjoin code paths do what the nestloop path is doing.
However, as I replied further down in that other thread, I'm not
exactly convinced that the nestloop path is doing the right thing.
I've not had time to look closer at that, though.
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2024-01-06 22:41:14 | Re: Wrong rows estimations with joins of CTEs slows queries by more than factor 500 |
Previous Message | Tom Lane | 2024-01-06 20:59:36 | Re: Wrong results with grouping sets |