aboutsummaryrefslogtreecommitdiff
path: root/src/backend/commands
diff options
context:
space:
mode:
authorTom Lane <tgl@sss.pgh.pa.us>2021-08-27 19:42:42 -0400
committerTom Lane <tgl@sss.pgh.pa.us>2021-08-27 19:53:06 -0400
commite84d4810cd47d83a6a864fa33db74bcc5570dd76 (patch)
tree9ab9368f51701ac4a8a9b6e5867918890c4a184b /src/backend/commands
parent9efa998a6403c5fe973ce5801d09ffa63e706eb6 (diff)
downloadpostgresql-e84d4810cd47d83a6a864fa33db74bcc5570dd76.tar.gz
postgresql-e84d4810cd47d83a6a864fa33db74bcc5570dd76.zip
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
Diffstat (limited to 'src/backend/commands')
0 files changed, 0 insertions, 0 deletions