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

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Seq Scan because of stats or because of cast?
Дата
Msg-id 1753797.1678715622@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Seq Scan because of stats or because of cast?  (Dominique Devienne <ddevienne@gmail.com>)
Ответы Re: Seq Scan because of stats or because of cast?  (Dominique Devienne <ddevienne@gmail.com>)
Re: Seq Scan because of stats or because of cast?  (Dominique Devienne <ddevienne@gmail.com>)
Список pgsql-general
Dominique Devienne <ddevienne@gmail.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



В списке pgsql-general по дате отправления:

Предыдущее
От: Dominique Devienne
Дата:
Сообщение: Seq Scan because of stats or because of cast?
Следующее
От: Raivo Rebane
Дата:
Сообщение: Binary large object processing problems