Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (but not seq_tup_read)

From: Kasahara Tatsuhito <kasahara(dot)tatsuhito(at)gmail(dot)com>
To: pgsql-hackers(at)postgresql(dot)org
Subject: Re: Tid scan increments value of pg_stat_all_tables.seq_scan. (but not seq_tup_read)
Date: 2020-01-29 11:06:06
Message-ID: CAP0=ZVKfwr2Bo42tqnb_W8GOk9QpGg5ywHYCU3Ue+Vn4Zt3B7g@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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(dot)tatsuhito(at)gmail(dot)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 Content-Type Size
fix_tidscan_increments_seqscan_num.patch application/octet-stream 1.6 KB

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Julien Rouhaud 2020-01-29 11:15:59 Re: BUG #16109: Postgres planning time is high across version (Expose buffer usage during planning in EXPLAIN)
Previous Message vignesh C 2020-01-29 11:03:44 Re: closesocket behavior in different platforms