Tid scan increments value of pg_stat_all_tables.seq_scan. (but not seq_tup_read) - Mailing list pgsql-hackers

From Kasahara Tatsuhito
Subject Tid scan increments value of pg_stat_all_tables.seq_scan. (but not seq_tup_read)
Date
Msg-id CAP0=ZVKy+gTbFmB6X_UW0pP3WaeJ-fkUWHoD-pExS=at3CY76g@mail.gmail.com
Whole thread Raw
Responses Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (butnot seq_tup_read)  (Kasahara Tatsuhito <kasahara.tatsuhito@gmail.com>)
List pgsql-hackers
Hi, I noticed that since PostgreSQL 12, Tid scan increments value of
pg_stat_all_tables.seq_scan. (but not seq_tup_read)

The following is an example.

CREATE TABLE t (c int);
INSERT INTO t SELECT 1;
SET enable_seqscan to off;

(v12 -)
=# EXPLAIN ANALYZE SELECT * FROM t WHERE ctid = '(0,1)';
                                        QUERY PLAN
-------------------------------------------------------------------------------------------
 Tid Scan on t  (cost=0.00..4.01 rows=1 width=4) (actual
time=0.034..0.035 rows=1 loops=1)
   TID Cond: (ctid = '(0,1)'::tid)
 Planning Time: 0.341 ms
 Execution Time: 0.059 ms
(4 rows)

=# SELECT seq_scan, seq_tup_read FROM pg_stat_user_tables WHERE relname = 't';
 seq_scan | seq_tup_read
----------+--------------
        1 |            0
(1 row)

(- v11)
=# EXPLAIN ANALYZE SELECT * FROM t WHERE ctid = '(0,1)';
                                        QUERY PLAN
-------------------------------------------------------------------------------------------
 Tid Scan on t  (cost=0.00..4.01 rows=1 width=4) (actual
time=0.026..0.027 rows=1 loops=1)
   TID Cond: (ctid = '(0,1)'::tid)
 Planning Time: 1.003 ms
 Execution Time: 0.068 ms
(4 rows)

postgres=# SELECT seq_scan, seq_tup_read FROM pg_stat_user_tables
WHERE relname = 't';
 seq_scan | seq_tup_read
----------+--------------
        0 |            0
(1 row)


Exactly, this change occurred from following commit.
https://git.postgresql.org/gitweb/?p=postgresql.git;a=commit;h=147e3722f7e531f15ba389a4d518efe8cd0bd736)
I think, from this commit, TidListEval() came to call
table_beginscan() , so this increments would be happen.

I'm not sure this change whether intention or not, it can confuse some users.

Best regards,
--
NTT Open Source Software Center
Tatsuhito Kasahara



pgsql-hackers by date:

Previous
From: Amit Langote
Date:
Subject: Re: table partitioning and access privileges
Next
From: Justin Pryzby
Date:
Subject: Re: error context for vacuum to include block number