Fix to increment the index scan counter for the bloom filter index
Hi,
I noticed that the bloom filter index forgets to increment the index
scan counter
while reviewing the skip scan patch [1]/messages/by-id/CAH2-Wz=M_8UCPpD5GQuJXmQZ6xePwhVSss38TmkBAwic12VvCg@mail.gmail.com. It seems this was simply
overlooked in
the implementation. What do you think?
# A test case:
## HEAD: 3f323eba89fb
CREATE EXTENSION bloom ;
CREATE TABLE tbloom AS
SELECT
(random() * 1000000)::int as i1,
(random() * 1000000)::int as i2,
(random() * 1000000)::int as i3,
(random() * 1000000)::int as i4,
(random() * 1000000)::int as i5,
(random() * 1000000)::int as i6
FROM
generate_series(1,10000000);
CREATE INDEX bloomidx ON tbloom USING bloom (i1, i2, i3, i4, i5, i6);
ANALYZE;
psql=# SELECT * FROM pg_stat_user_indexes ;
-[ RECORD 1 ]-+---------
relid | 16384
indexrelid | 16398
schemaname | public
relname | tbloom
indexrelname | bloomidx
idx_scan | 0
last_idx_scan |
idx_tup_read | 0
idx_tup_fetch | 0
psql=# SET enable_seqscan = off;
psql=# EXPLAIN ANALYZE SELECT * FROM tbloom WHERE i2 = 898732 AND i5 =
123451;
postgres=# SELECT * FROM pg_stat_user_indexes ;
-[ RECORD 1 ]-+---------
relid | 16384
indexrelid | 16398
schemaname | public
relname | tbloom
indexrelname | bloomidx
idx_scan | 0 # was not incremented
last_idx_scan | #
idx_tup_read | 2362 # was incremented. It indicates
that an index scan was executed
idx_tup_fetch | 0
## HEAD with the v1 patch
-- after EXPLAIN ANALYZE ...
postgres=# SELECT * FROM pg_stat_user_indexes ;
-[ RECORD 1 ]-+------------------------------
relid | 16395
indexrelid | 16398
schemaname | public
relname | tbloom
indexrelname | bloomidx
idx_scan | 1 # was incremented
too
last_idx_scan | 2024-11-12 18:15:39.270747+09 #
idx_tup_read | 2503 #
idx_tup_fetch | 0
[1]: /messages/by-id/CAH2-Wz=M_8UCPpD5GQuJXmQZ6xePwhVSss38TmkBAwic12VvCg@mail.gmail.com
/messages/by-id/CAH2-Wz=M_8UCPpD5GQuJXmQZ6xePwhVSss38TmkBAwic12VvCg@mail.gmail.com
Regards,
--
Masahiro Ikeda
NTT DATA CORPORATION
Attachments:
v1-0001-Modify-to-increment-the-index-scan-counter-for-Bl.patchtext/x-diff; name=v1-0001-Modify-to-increment-the-index-scan-counter-for-Bl.patchDownload
From 33fed0e2d5754a8adba44122c73779be4d7385bb Mon Sep 17 00:00:00 2001
From: Masahiro Ikeda <ikedamsh@oss.nttdata.com>
Date: Tue, 12 Nov 2024 18:22:11 +0900
Subject: [PATCH v1] Modify to increment the index scan counter for the
bloom filter index.
---
contrib/bloom/blscan.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/contrib/bloom/blscan.c b/contrib/bloom/blscan.c
index bf455e579f..0c5fb725e8 100644
--- a/contrib/bloom/blscan.c
+++ b/contrib/bloom/blscan.c
@@ -15,6 +15,7 @@
#include "access/relscan.h"
#include "bloom.h"
#include "miscadmin.h"
+#include "pgstat.h"
#include "storage/bufmgr.h"
/*
@@ -114,6 +115,7 @@ blgetbitmap(IndexScanDesc scan, TIDBitmap *tbm)
*/
bas = GetAccessStrategy(BAS_BULKREAD);
npages = RelationGetNumberOfBlocks(scan->indexRelation);
+ pgstat_count_index_scan(scan->indexRelation);
for (blkno = BLOOM_HEAD_BLKNO; blkno < npages; blkno++)
{
--
2.34.1
On Tue, Nov 12, 2024 at 5:01 AM Masahiro Ikeda <ikedamsh@oss.nttdata.com> wrote:
I noticed that the bloom filter index forgets to increment the index
scan counter
while reviewing the skip scan patch [1]. It seems this was simply
overlooked in
the implementation. What do you think?
I think that you're right.
I'll commit this and backpatch once the release tags for the pending
set of point releases are pushed.
--
Peter Geoghegan
On 2024-11-13 06:23, Peter Geoghegan wrote:
On Tue, Nov 12, 2024 at 5:01 AM Masahiro Ikeda
<ikedamsh@oss.nttdata.com> wrote:I noticed that the bloom filter index forgets to increment the index
scan counter
while reviewing the skip scan patch [1]. It seems this was simply
overlooked in
the implementation. What do you think?I think that you're right.
I'll commit this and backpatch once the release tags for the pending
set of point releases are pushed.
OK, thanks.
Regards,
--
Masahiro Ikeda
NTT DATA CORPORATION
On Tue, Nov 12, 2024 at 7:45 PM Masahiro Ikeda <ikedamsh@oss.nttdata.com> wrote:
On 2024-11-13 06:23, Peter Geoghegan wrote:
I'll commit this and backpatch once the release tags for the pending
set of point releases are pushed.OK, thanks.
Pushed.
Thanks
--
Peter Geoghegan