Re: wrong rows estimation by hash join

From: Tomas Vondra <tomas(dot)vondra(at)enterprisedb(dot)com>
To: "James Pang (chaolpan)" <chaolpan(at)cisco(dot)com>, "pgsql-performance(at)lists(dot)postgresql(dot)org" <pgsql-performance(at)lists(dot)postgresql(dot)org>
Subject: Re: wrong rows estimation by hash join
Date: 2023-06-10 20:38:31
Message-ID: 8f79dacb-332e-7bde-e9e9-1a2319aa51f4@enterprisedb.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

Hi,

On 6/9/23 10:36, James Pang (chaolpan) wrote:
>   How does hash join estimation rows ?   pg v14, it make wrong rows
> estimation then leave nest loop lef join that make poor sql plan.  A
>

I doubt this is specific to hashjoins, we estimate cardinality the same
way for all joins (or more precisely, we estimate it before picking the
particular join method).

I'm just guessing, but I'd bet the join condition is correlated with the
filter on cs_contract:

> ->  Index
> Scan using cs_xxxx_test on cs_contract cc  (cost=0.43..167540.92
> rows=237989 width=115)
> Index Cond: ((xx_to > CURRENT_DATE) AND ((status)::text = ANY
> ('{Active,Inactive,Pending}'::text[])))
>

If you remove that condition, does the estimate improve?

regards

--
Tomas Vondra
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Browse pgsql-performance by date

  From Date Subject
Next Message James Pang (chaolpan) 2023-06-12 08:09:28 Postgresql equal join on function with columns not use index
Previous Message James Pang (chaolpan) 2023-06-09 08:36:01 wrong rows estimation by hash join