pg.ddx.io pgsql-bugs@postgresql.org mailing list archive
help / color / mirror / Atom feedBUG #17163: spgist index scan statistics stays at 0
3+ messages / 2 participants
[nested] [flat]
* BUG #17163: spgist index scan statistics stays at 0
@ 2021-08-27 07:18 PG Bug reporting form <noreply@postgresql.org>
2021-08-27 18:33 ` Re: BUG #17163: spgist index scan statistics stays at 0 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 3+ messages in thread
From: PG Bug reporting form @ 2021-08-27 07:18 UTC (permalink / raw)
To: pgsql-bugs@lists.postgresql.org; +Cc: github@cquest.org
The following bug has been logged on the website:
Bug reference: 17163
Logged by: Christian Quest
Email address: github@cquest.org
PostgreSQL version: 13.4
Operating system: Ubuntu 20.04
Description:
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.
^ permalink raw reply [nested|flat] 3+ messages in thread
* Re: BUG #17163: spgist index scan statistics stays at 0
2021-08-27 07:18 BUG #17163: spgist index scan statistics stays at 0 PG Bug reporting form <noreply@postgresql.org>
@ 2021-08-27 18:33 ` Tom Lane <tgl@sss.pgh.pa.us>
2021-08-27 22:48 ` Re: BUG #17163: spgist index scan statistics stays at 0 Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 3+ messages in thread
From: Tom Lane @ 2021-08-27 18:33 UTC (permalink / raw)
To: github@cquest.org; +Cc: pgsql-bugs@lists.postgresql.org
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
Attachments:
count-spgist-indexscans-1.patch (text/x-diff, 664B) download
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
* Re: BUG #17163: spgist index scan statistics stays at 0
2021-08-27 07:18 BUG #17163: spgist index scan statistics stays at 0 PG Bug reporting form <noreply@postgresql.org>
2021-08-27 18:33 ` Re: BUG #17163: spgist index scan statistics stays at 0 Tom Lane <tgl@sss.pgh.pa.us>
@ 2021-08-27 22:48 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 3+ messages in thread
From: Tom Lane @ 2021-08-27 22:48 UTC (permalink / raw)
To: github@cquest.org; +Cc: pgsql-bugs@lists.postgresql.org
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
^ permalink raw reply [nested|flat] 3+ messages in thread
end of thread, other threads:[~2021-08-27 22:48 UTC | newest]
Thread overview: 3+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
2021-08-27 07:18 BUG #17163: spgist index scan statistics stays at 0 PG Bug reporting form <noreply@postgresql.org>
2021-08-27 18:33 ` Tom Lane <tgl@sss.pgh.pa.us>
2021-08-27 22:48 ` Tom Lane <tgl@sss.pgh.pa.us>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox