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 |
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 |