From: | Andrei Lepikhov <lepihov(at)gmail(dot)com> |
---|---|
To: | Frits Jalvingh <jal(at)etc(dot)to> |
Cc: | "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Question about nested loops.. |
Date: | 2025-10-10 09:28:44 |
Message-ID: | d10b91e6-76eb-4a6c-bb17-c5736577f5ea@gmail.com |
Views: | Whole Thread | Raw Message | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On 10/10/2025 10:51, Frits Jalvingh wrote:
> Hi Andrei,
> Thanks a lot for your response. I do not fully get it though because the
> well-performing query also references the outer (external?) relation:
> -> where eenheid.id_h_eenheid = eenheid_s.id_h_eenheid
> But your response made me think a but more.This is the schema of EXPLAIN for the second 'optimal' query:
Seq Scan on s_h_eenheid_ssm D
SubPlan 2
-> Hash Join
Hash Cond: (A.x = B.x)
-> Seq Scan on A
Filter: ...
-> Hash
-> Hash Join
Hash Cond: (C.y = B.x)
-> Seq Scan on s_h_huurovereenkomst_ssm C
-> Hash
-> Seq Scan on s_h_eenheid_ssm B
There is no reference to the upper relation D - each HashJoin refers to
its left and right side only.
-- regards, Andrei Lepikhov, pgEdge
From | Date | Subject | |
---|---|---|---|
Next Message | David G. Johnston | 2025-10-11 23:03:37 | Re: Poor performance with row wise comparisons |
Previous Message | lokesh | 2025-10-10 04:21:01 | Re: Poor performance with row wise comparisons |