Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
Skip to content

Commit 3778bcb

Browse files
committed
Count SP-GiST index scans in pg_stat statistics.
Somehow, spgist overlooked the need to call pgstat_count_index_scan(). Hence, pg_stat_all_indexes.idx_scan and equivalent columns never became nonzero for an SP-GiST index, although the related per-tuple counters worked fine. This fix works a bit differently from other index AMs, in that the counter increment occurs in spgrescan not spggettuple/spggetbitmap. It looks like this won't make the user-visible semantics noticeably different, so I won't go to the trouble of introducing an is-this- the-first-call flag just to make the counter bumps happen in the same places. Per bug #17163 from Christian Quest. Back-patch to all supported versions. Discussion: https://postgr.es/m/17163-b8c5cc88322a5e92@postgresql.org
1 parent ce42efa commit 3778bcb

File tree

1 file changed

+4
-0
lines changed

1 file changed

+4
-0
lines changed

src/backend/access/spgist/spgscan.c

+4
Original file line numberDiff line numberDiff line change
@@ -19,6 +19,7 @@
1919
#include "access/relscan.h"
2020
#include "access/spgist_private.h"
2121
#include "miscadmin.h"
22+
#include "pgstat.h"
2223
#include "storage/bufmgr.h"
2324
#include "utils/datum.h"
2425
#include "utils/float.h"
@@ -419,6 +420,9 @@ spgrescan(IndexScanDesc scan, ScanKey scankey, int nscankeys,
419420

420421
/* set up starting queue entries */
421422
resetSpGistScanOpaque(so);
423+
424+
/* count an indexscan for stats */
425+
pgstat_count_index_scan(scan->indexRelation);
422426
}
423427

424428
void

0 commit comments

Comments
 (0)