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: Check lateral references within PHVs for memoize cache keys |
Date: | 2023-07-13 09:21:03 |
Message-ID: | CAMbWs48MwUKRKsPuG3uy_=UwcpE+ZHoGD5j3inHLPj=Q_0bsTg@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Sun, Jul 9, 2023 at 1:28 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
> More generally, it's not clear to me why we should need to look inside
> lateral PHVs in the first place. Wouldn't the lateral PHV itself
> serve fine as a cache key?
Do you mean we use the lateral PHV directly as a cache key? Hmm, it
seems to me that we'd have problem if the PHV references rels that are
inside the PHV's syntactic scope. For instance
select * from t t1 left join
lateral (select t1.a+t2.a as t1a, t2.a as t2a from t t2) s on true
where s.t1a = s.t2a;
The PHV references t1.a so it's lateral. But it also references t2.a,
so if we use the PHV itself as cache key, the plan would look like
QUERY PLAN
----------------------------------------
Nested Loop
-> Seq Scan on t t1
-> Memoize
Cache Key: (t1.a + t2.a)
Cache Mode: binary
-> Seq Scan on t t2
Filter: ((t1.a + a) = a)
(7 rows)
which is an invalid plan as the cache key contains t2.a.
Thanks
Richard
From | Date | Subject | |
---|---|---|---|
Next Message | Alvaro Herrera | 2023-07-13 09:29:05 | Re: Consistent coding for the naming of LR workers |
Previous Message | Amit Kapila | 2023-07-13 09:16:22 | Re: [Patch] Use *other* indexes on the subscriber when REPLICA IDENTITY is FULL |