From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Richard Guo <guofenglinux(at)gmail(dot)com> |
Cc: | zuming(dot)jiang(at)inf(dot)ethz(dot)ch, Alexander Korotkov <aekorotkov(at)gmail(dot)com>, pgsql-bugs(at)lists(dot)postgresql(dot)org |
Subject: | Re: BUG #18261: Inconsistent results of SELECT affected by joined subqueries |
Date: | 2023-12-28 16:32:55 |
Message-ID: | 2887250.1703781175@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-bugs |
Richard Guo <guofenglinux(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Bruce Momjian | 2023-12-28 16:46:03 | Re: Out of the box, full text search feature suggestion for postgresql |
Previous Message | aa | 2023-12-28 15:15:07 | Out of the box, full text search feature suggestion for postgresql |