Horton

Thread

Commits

  1. Count contrib/bloom index scans in pgstat view.

  1. Fix to increment the index scan counter for the bloom filter index

    Masahiro Ikeda <ikedamsh@oss.nttdata.com> — 2024-11-12T10:01:47Z

    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

  2. Re: Fix to increment the index scan counter for the bloom filter index

    Peter Geoghegan <pg@bowt.ie> — 2024-11-12T21:23:10Z

    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

  3. Re: Fix to increment the index scan counter for the bloom filter index

    Masahiro Ikeda <ikedamsh@oss.nttdata.com> — 2024-11-13T00:45:04Z

    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

  4. Re: Fix to increment the index scan counter for the bloom filter index

    Peter Geoghegan <pg@bowt.ie> — 2024-11-13T01:58:57Z

    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