Re: Optimize cardinality estimation when unique keys are fully covered

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
--