Re: BUG #17163: spgist index scan statistics stays at 0
От | Tom Lane |
---|---|
Тема | Re: BUG #17163: spgist index scan statistics stays at 0 |
Дата | |
Msg-id | 862973.1630089184@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | BUG #17163: spgist index scan statistics stays at 0 (PG Bug reporting form <noreply@postgresql.org>) |
Ответы |
Re: BUG #17163: spgist index scan statistics stays at 0
|
Список | pgsql-bugs |
PG Bug reporting form <noreply@postgresql.org> writes: > The idx_scan in pg_stat_all_indexes stays at 0 for spgist index, while the > idx_tup_read and idx_tup_fetch and correctly updated. Hmm, you're right, there's no pgstat_count_index_scan anywhere in access/spgist/ :-( The other index AMs do that during the first amgettuple or amgetbitmap call, but it doesn't look like there is any convenient way to duplicate that behavior in spgist; none of the code in or below spggettuple or spggetbitmap is explicitly aware of whether this is the first call. I'm inclined to propose adding the counter bump in spgrescan. That isn't *exactly* equivalent semantics, but it would only matter if someplace called amrescan and then didn't follow through with a scan. The attached seems to behave as I'd expect. regards, tom lane diff --git a/src/backend/access/spgist/spgscan.c b/src/backend/access/spgist/spgscan.c index e14b9fa573..401a1a8343 100644 --- a/src/backend/access/spgist/spgscan.c +++ b/src/backend/access/spgist/spgscan.c @@ -19,6 +19,7 @@ #include "access/relscan.h" #include "access/spgist_private.h" #include "miscadmin.h" +#include "pgstat.h" #include "storage/bufmgr.h" #include "utils/datum.h" #include "utils/float.h" @@ -419,6 +420,9 @@ spgrescan(IndexScanDesc scan, ScanKey scankey, int nscankeys, /* set up starting queue entries */ resetSpGistScanOpaque(so); + + /* count an indexscan for stats */ + pgstat_count_index_scan(scan->indexRelation); } void
В списке pgsql-bugs по дате отправления: