Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (butnot seq_tup_read) - Mailing list pgsql-hackers

From Kasahara Tatsuhito
Subject Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (butnot seq_tup_read)
Date
Msg-id CAP0=ZVKfwr2Bo42tqnb_W8GOk9QpGg5ywHYCU3Ue+Vn4Zt3B7g@mail.gmail.com
Whole thread Raw
In response to Tid scan increments value of pg_stat_all_tables.seq_scan. (but not seq_tup_read)  (Kasahara Tatsuhito <kasahara.tatsuhito@gmail.com>)
Responses Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (butnot seq_tup_read)  (Fujii Masao <masao.fujii@oss.nttdata.com>)
List pgsql-hackers
Hi.

Attached patch solve this problem.

This patch adds table_beginscan_tid() and call it in TidListEval()
instead of table_beginscan().
table_beginscan_tid() is the same as table_beginscan() but do not set
SO_TYPE_SEQSCAN to flags.

Although I'm not sure this behavior is really problem or not,
it seems to me that previous behavior is more prefer.

Is it worth to apply to HEAD and v12 branch ?

Best regards,

2020年1月27日(月) 14:35 Kasahara Tatsuhito <kasahara.tatsuhito@gmail.com>:
>
> 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



--
Tatsuhito Kasahara
kasahara.tatsuhito _at_ gmail.com

Attachment

pgsql-hackers by date:

Previous
From: vignesh C
Date:
Subject: Re: closesocket behavior in different platforms
Next
From: Julien Rouhaud
Date:
Subject: Re: BUG #16109: Postgres planning time is high across version (Exposebuffer usage during planning in EXPLAIN)