> On Nov 22, 2025, at 02:52, Tom Lane wrote:
>
> "=?utf-8?B?ZmVpY2hhbmdob25n?=" writes:
>> We may consider checking in cardinality estimation whether the restrictlist
>> fully covers a unique index. If so, we can directly set the estimated rows
>> to 1. The attached patch provides a very early
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 f
"=?utf-8?B?ZmVpY2hhbmdob25n?=" writes:
> We may consider checking in cardinality estimation whether the restrictlist
> fully covers a unique index. If so, we can directly set the estimated rows
> to 1. The attached patch provides a very early demo of this approach.
I think this is far harder than
> On Nov 22, 2025, at 00:54, feichanghong wrote:
>
> Hi,
>
> Recently, I ran into a cardinality estimation problem where the query
> predicates fully cover a primary key or unique index. The issue can be
> reproduced with the following case:
>
> ```sql
> create table t1(a int, b int, primary
Hi,
Recently, I ran into a cardinality estimation problem where the query
predicates fully cover a primary key or unique index. The issue can be
reproduced with the following case:
```sql
create table t1(a int, b int, primary key(a, b));
DO $$
DECLARE
i integer;
BEGIN
FOR i IN 1..1000
