From: | Alexander Korotkov <aekorotkov(at)gmail(dot)com> |
---|---|
To: | Alexander Lakhin <exclusion(at)gmail(dot)com> |
Cc: | Andrei Lepikhov <a(dot)lepikhov(at)postgrespro(dot)ru>, "Gregory Stark (as CFM)" <stark(dot)cfm(at)gmail(dot)com>, Michał Kłeczek <michal(at)kleczek(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org>, Richard Guo <guofenglinux(at)gmail(dot)com> |
Subject: | Re: Removing unneeded self joins |
Date: | 2024-01-09 06:08:37 |
Message-ID: | CAPpHfdsqe6wOkegR3QDeuNCZo3YMR2Nmeg2OXmdWgrbcJRDY7Q@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Jan 9, 2024 at 6:00 AM Alexander Lakhin <exclusion(at)gmail(dot)com> wrote:
> 09.01.2024 01:09, Alexander Korotkov wrote:
> > Fixed in 30b4955a46.
>
> Thank you for fixing that!
>
> I've found another anomaly coined with d3d55ce57. This query:
> CREATE TABLE t(a int PRIMARY KEY, b int);
> INSERT INTO t VALUES (1, 1), (2, 1);
>
> WITH t1 AS (SELECT * FROM t)
> UPDATE t SET b = t1.b + 1 FROM t1
> WHERE t.a = t1.a RETURNING t.a, t1.b;
>
> gives "ERROR: variable not found in subplan target lists" on d3d55ce57, but
> starting from a7928a57b it gives an incorrect result:
> a | b
> ---+---
> 1 | 2
> 2 | 2
> (2 rows)
I see. It seems to be not safe to apply SJE to the modify table
target relation because it could use a different snapshot for the
RETURNING clause. I think we should just forbid SJE to involve the
modify table target relation. I'm planning to fix this later today.
------
Regards,
Alexander Korotkov
From | Date | Subject | |
---|---|---|---|
Next Message | vignesh C | 2024-01-09 06:24:19 | Re: Speed up transaction completion faster after many relations are accessed in a transaction |
Previous Message | Michael Paquier | 2024-01-09 05:56:34 | Re: Emit fewer vacuum records by reaping removable tuples during pruning |