Re: BUG #17163: spgist index scan statistics stays at 0
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: github@cquest.org
Cc: pgsql-bugs@lists.postgresql.org
Date: 2021-08-27T22:48:46Z
Lists: pgsql-bugs
I wrote: > 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. I had a nagging feeling that we might have multiple amrescan calls in some code paths, but after reviewing the commit log, it looks like that stopped being an issue in 9.1 (commit d583f10b7). So it should be okay to do it like this in supported branches. regards, tom lane
Commits
-
Count SP-GiST index scans in pg_stat statistics.
- e84d4810cd47 14.0 landed
- 3778bcb39a94 15.0 landed
- dbb239d518ee 13.5 landed
- 9e959f7ed5d5 9.6.24 landed
- 7c1b0f4c3535 11.14 landed
- 6a787c83c48a 10.19 landed
- 187b5fea982e 12.9 landed
-
Create core infrastructure for KNNGIST.
- d583f10b7e0b 9.1.0 cited