Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tAnif-000Bm0-Ju for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Nov 2024 10:01:56 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1tAnic-004sAa-Fp for pgsql-hackers@arkaria.postgresql.org; Tue, 12 Nov 2024 10:01:55 +0000 Received: from makus.postgresql.org ([2001:4800:3e1:1::229]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tAnic-004sAS-2F for pgsql-hackers@lists.postgresql.org; Tue, 12 Nov 2024 10:01:54 +0000 Received: from oss.nttdata.com ([49.212.34.109]) by makus.postgresql.org with esmtps (TLS1.2) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1tAniZ-001Sh8-9P for pgsql-hackers@postgresql.org; Tue, 12 Nov 2024 10:01:53 +0000 Received: from oss.nttdata.com (localhost [127.0.0.1]) by oss.nttdata.com (Postfix) with ESMTPA id C9945614E4 for ; Tue, 12 Nov 2024 19:01:47 +0900 (JST) X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.103.11 at oss.nttdata.com MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=_b50b4efb3eb5772ccbac0f9282c11fdd" Content-Transfer-Encoding: 7bit Date: Tue, 12 Nov 2024 19:01:47 +0900 From: Masahiro Ikeda To: pgsql-hackers@postgresql.org Subject: Fix to increment the index scan counter for the bloom filter index User-Agent: Roundcube Webmail/1.4.11 Message-ID: X-Sender: ikedamsh@oss.nttdata.com List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk --=_b50b4efb3eb5772ccbac0f9282c11fdd Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII; format=flowed Hi, 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? # 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] https://www.postgresql.org/message-id/flat/CAH2-Wz%3DM_8UCPpD5GQuJXmQZ6xePwhVSss38TmkBAwic12VvCg%40mail.gmail.com#ffef7ecf393d0008c5ded2d2184a71f9 Regards, -- Masahiro Ikeda NTT DATA CORPORATION --=_b50b4efb3eb5772ccbac0f9282c11fdd Content-Transfer-Encoding: base64 Content-Type: text/x-diff; name=v1-0001-Modify-to-increment-the-index-scan-counter-for-Bl.patch Content-Disposition: attachment; filename=v1-0001-Modify-to-increment-the-index-scan-counter-for-Bl.patch; size=918 RnJvbSAzM2ZlZDBlMmQ1NzU0YThhZGJhNDQxMjJjNzM3NzliZTRkNzM4NWJiIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBNYXNhaGlybyBJa2VkYSA8aWtlZGFtc2hAb3NzLm50dGRhdGEu Y29tPgpEYXRlOiBUdWUsIDEyIE5vdiAyMDI0IDE4OjIyOjExICswOTAwClN1YmplY3Q6IFtQQVRD SCB2MV0gTW9kaWZ5IHRvIGluY3JlbWVudCB0aGUgaW5kZXggc2NhbiBjb3VudGVyIGZvciB0aGUK Ymxvb20gZmlsdGVyIGluZGV4LgoKLS0tCiBjb250cmliL2Jsb29tL2Jsc2Nhbi5jIHwgMiArKwog MSBmaWxlIGNoYW5nZWQsIDIgaW5zZXJ0aW9ucygrKQoKZGlmZiAtLWdpdCBhL2NvbnRyaWIvYmxv b20vYmxzY2FuLmMgYi9jb250cmliL2Jsb29tL2Jsc2Nhbi5jCmluZGV4IGJmNDU1ZTU3OWYuLjBj NWZiNzI1ZTggMTAwNjQ0Ci0tLSBhL2NvbnRyaWIvYmxvb20vYmxzY2FuLmMKKysrIGIvY29udHJp Yi9ibG9vbS9ibHNjYW4uYwpAQCAtMTUsNiArMTUsNyBAQAogI2luY2x1ZGUgImFjY2Vzcy9yZWxz Y2FuLmgiCiAjaW5jbHVkZSAiYmxvb20uaCIKICNpbmNsdWRlICJtaXNjYWRtaW4uaCIKKyNpbmNs dWRlICJwZ3N0YXQuaCIKICNpbmNsdWRlICJzdG9yYWdlL2J1Zm1nci5oIgogCiAvKgpAQCAtMTE0 LDYgKzExNSw3IEBAIGJsZ2V0Yml0bWFwKEluZGV4U2NhbkRlc2Mgc2NhbiwgVElEQml0bWFwICp0 Ym0pCiAJICovCiAJYmFzID0gR2V0QWNjZXNzU3RyYXRlZ3koQkFTX0JVTEtSRUFEKTsKIAlucGFn ZXMgPSBSZWxhdGlvbkdldE51bWJlck9mQmxvY2tzKHNjYW4tPmluZGV4UmVsYXRpb24pOworCXBn c3RhdF9jb3VudF9pbmRleF9zY2FuKHNjYW4tPmluZGV4UmVsYXRpb24pOwogCiAJZm9yIChibGtu byA9IEJMT09NX0hFQURfQkxLTk87IGJsa25vIDwgbnBhZ2VzOyBibGtubysrKQogCXsKLS0gCjIu MzQuMQoK --=_b50b4efb3eb5772ccbac0f9282c11fdd--