From: | Richard Guo <guofenglinux(at)gmail(dot)com> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Inconsistent nullingrels due to oversight in deconstruct_distribute_oj_quals |
Date: | 2023-02-10 03:08:10 |
Message-ID: | CAMbWs485DSqPD9fZLEPZDmRiFy5tH5NLYsvA_OtRM453s5uqEw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Thu, Feb 9, 2023 at 11:55 PM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> Richard Guo <guofenglinux(at)gmail(dot)com> writes:
> > This query would trigger the Assert() in search_indexed_tlist_for_var.
> > So I wonder that we should use othersj->syn_righthand here.
>
> There are two such calls in deconstruct_distribute_oj_quals ...
> don't they both need this change?
Yeah, I wondered about that too, but didn't manage to devise a query
that can show the problem caused by the call for 'above_sjinfo' case.
After a night of sleep I came up with one this morning. :-)
create table t (a int, b int);
insert into t select i, i from generate_series(1,10)i;
analyze t;
select * from t t1 left join t t2 left join t t3 on t2.b = t3.b left join t
t4 on t2.a > t3.a on t2.a > t1.a;
In this query, for the qual 't2.a > t3.a', when we try to push t3/t4
join to above t1/t2 join, we fail to add t1/t2 ojrelid to
nullingrels of t3.a, because t3 is not in t1/t2 join's min_righthand
(but in its syn_righthand). We really should have done that because
after the commutation t1/t2 join can null not only t2 but also t3 in
this case.
Thanks
Richard
From | Date | Subject | |
---|---|---|---|
Next Message | Peter Smith | 2023-02-10 03:26:35 | Re: Perform streaming logical transactions by background workers and parallel apply |
Previous Message | Michael Paquier | 2023-02-10 03:07:36 | Re: recovery modules |