Re: BUG #17163: spgist index scan statistics stays at 0

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: github(at)cquest(dot)org
Cc: pgsql-bugs(at)lists(dot)postgresql(dot)org
Subject: Re: BUG #17163: spgist index scan statistics stays at 0
Date: 2021-08-27 18:33:04
Message-ID: 862973.1630089184@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

PG Bug reporting form <noreply(at)postgresql(dot)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

Attachment Content-Type Size
count-spgist-indexscans-1.patch text/x-diff 665 bytes

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Tom Lane 2021-08-27 22:48:46 Re: BUG #17163: spgist index scan statistics stays at 0
Previous Message PG Bug reporting form 2021-08-27 16:07:11 BUG #17164: Running initdb from default Administrator account results in error