From: Tom Lane <tgl@sss.pgh.pa.us>
To: Richard Guo <guofenglinux@gmail.com>
Cc: zuming.jiang@inf.ethz.ch, Alexander Korotkov <aekorotkov@gmail.com>
Cc: pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18261: Inconsistent results of SELECT affected by joined subqueries
Date: Thu, 28 Dec 2023 11:32:55 -0500
Message-ID: <2887250.1703781175@sss.pgh.pa.us> (raw)
In-Reply-To: <CAMbWs48_EAPrc_C5qvK2WGvydHvht1JUnXwer9FVeU7t_zA+MQ@mail.gmail.com>
References: <18261-2a75d748c928609b@postgresql.org>
<CAMbWs48_EAPrc_C5qvK2WGvydHvht1JUnXwer9FVeU7t_zA+MQ@mail.gmail.com>
Richard Guo <guofenglinux@gmail.com> writes:
> I've looked into it a bit. The problem lies in how the SJE code handles
> the transfer of qual clauses from the removed relation to the remaining
> one.
I am definitely starting to think that the SJE patch was not ready
for prime time. We keep finding not only minor but major problems
in it --- I'd call this one a "major" one. Is it time to revert
and rethink it from scratch?
> If we determine that avoiding duplicates is necessary, I think at least
> we should compare the entire RestrictInfos not just their clauses. One
> challenge with this approach is that the 'rinfo_serial' usually differs,
> making direct comparison problematic. I'm wondering if we can make
> 'rinfo_serial' equal_ignore. Not too sure about that.
I'd say that that will break the cases rinfo_serial was introduced for.
Now, I certainly don't love rinfo_serial and would be happier if we
could do without it, but getting rid of it is another research project.
regards, tom lane
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-bugs@postgresql.org
Cc: tgl@sss.pgh.pa.us, guofenglinux@gmail.com, aekorotkov@gmail.com, pgsql-bugs@lists.postgresql.org
Subject: Re: BUG #18261: Inconsistent results of SELECT affected by joined subqueries
In-Reply-To: <2887250.1703781175@sss.pgh.pa.us>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox