Re: Check lateral references within PHVs for memoize cache keys
От | Richard Guo |
---|---|
Тема | Re: Check lateral references within PHVs for memoize cache keys |
Дата | |
Msg-id | CAMbWs48MwUKRKsPuG3uy_=UwcpE+ZHoGD5j3inHLPj=Q_0bsTg@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Check lateral references within PHVs for memoize cache keys (Tom Lane <tgl@sss.pgh.pa.us>) |
Список | pgsql-hackers |
On Sun, Jul 9, 2023 at 1:28 AM Tom Lane <tgl@sss.pgh.pa.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
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
В списке pgsql-hackers по дате отправления: