Re: Seq Scan because of stats or because of cast?

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Dominique Devienne <ddevienne(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Seq Scan because of stats or because of cast?
Date: 2023-03-13 13:53:42
Message-ID: 1753797.1678715622@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Dominique Devienne <ddevienne(at)gmail(dot)com> writes:
> I figured that query would use the "pg_auth_members_role_member_index"
> index,
> but instead it's using a sequential scan.
> And I'm wondering is this is because the cardinality of that catalog is
> small (172),
> which is just an artifact of my dev-testing, or whether that's because I
> cast roleid
> to an int4, preventing the use of the index?

Both.

> Is there a way to know why the index is not used, in any of my attempts?

For testing purposes, you could set enable_seqscan = off and then see
whether the plan changes. When I try this example I get

regression=# explain select * from pg_auth_members WHERE roleid = ANY(array[1::oid,2::oid,3::oid]);
QUERY PLAN
----------------------------------------------------------------
Seq Scan on pg_auth_members (cost=0.00..1.04 rows=3 width=19)
Filter: (roleid = ANY ('{1,2,3}'::oid[]))
(2 rows)

regression=# set enable_seqscan to 0;
SET
regression=# explain select * from pg_auth_members WHERE roleid = ANY(array[1::oid,2::oid,3::oid]);
QUERY PLAN
-----------------------------------------------------------------------------------------------------------
Index Scan using pg_auth_members_role_member_index on pg_auth_members (cost=0.13..12.44 rows=3 width=19)
Index Cond: (roleid = ANY ('{1,2,3}'::oid[]))
(2 rows)

So it's clearly not going to use the index until pg_auth_members gets
a great deal larger than it is on my test installation --- but it's
capable of doing so once it looks cost-attractive.

> PS: libpq uses unsigned int for Oid. So do OIDs go above 2GB in practice?

Yes, eventually.

> I'm asking, since I'm casting to ::int4, thus if they do, then that
> case might overflow.

I'd use int8.

> PPS: Are OIDs recycled / reused? Or are they monotonically increasing?
> What happens when the Cluster runs out of OIDs?

The counter wraps around. But it does so at 2^32 not 2^31.

> Are they Cluster-wide unique or it depends on the OID type?

They're unique per catalog. We don't attempt to guarantee
more than that. In practice, they'll be unique across the
installation until after the first OID wraparound, and then
not so much.

regards, tom lane

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message Raivo Rebane 2023-03-13 15:00:52 Binary large object processing problems
Previous Message Dominique Devienne 2023-03-13 09:07:06 Seq Scan because of stats or because of cast?