Re: Optimize cardinality estimation when unique keys are fully covered - Mailing list pgsql-hackers

From Nico Williams
Subject Re: Optimize cardinality estimation when unique keys are fully covered
Date
Msg-id aSDC4ex5V4YbUxY/@ubby
Whole thread Raw
In response to Re: Optimize cardinality estimation when unique keys are fully covered  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Fri, Nov 21, 2025 at 01:52:07PM -0500, Tom Lane wrote:
> But the conclusion that "where t1.a = t2.a and t1.b = 0" means that
> t1's rowcount is 1 only applies if the join is implemented as an inner
> indexscan.  If we choose some other method, say a hash join based on
> a seqscan of t1, having forced that rowcount to 1 would produce
> completely false estimates.

But wouldn't knowing that for an inner indexscan the cardinality is one
then drive the optimizer to choose inner indexscan over other methods?

Nico
-- 



pgsql-hackers by date:

Previous
From: Jacob Champion
Date:
Subject: Re: RFC 9266: Channel Bindings for TLS 1.3 support
Next
From: Greg Burd
Date:
Subject: Re: [PATCH] Fix ARM64/MSVC atomic memory ordering issues on Win11 by adding explicit DMB ​barriers