Re: Showing I/O timings spent reading/writing temp buffers in EXPLAIN

From: Julien Rouhaud <rjuju123(at)gmail(dot)com>
To: Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>
Cc: gkokolatos(at)pm(dot)me, Ranier Vilela <ranier(dot)vf(at)gmail(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>, depesz(at)depesz(dot)com
Subject: Re: Showing I/O timings spent reading/writing temp buffers in EXPLAIN
Date: 2022-01-19 08:52:36
Message-ID: 20220119085236.iuuq4rtzm6qxvzls@jrouhaud
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi,

On Tue, Nov 16, 2021 at 04:37:44PM +0900, Masahiko Sawada wrote:
>
> I've attached an updated patch. Please review it.

It seems that the regression tests aren't entirely stable, per cfbot:
https://cirrus-ci.com/github/postgresql-cfbot/postgresql/commitfest/36/3298.

The failures look like:

diff -U3 /tmp/cirrus-ci-build/src/test/recovery/../regress/expected/explain.out /tmp/cirrus-ci-build/src/test/recovery/tmp_check/results/explain.out
--- /tmp/cirrus-ci-build/src/test/recovery/../regress/expected/explain.out 2022-01-19 03:50:37.087931908 +0000
+++ /tmp/cirrus-ci-build/src/test/recovery/tmp_check/results/explain.out 2022-01-19 03:57:41.013616137 +0000
@@ -512,9 +512,10 @@
I/O Timings: temp read=N.N write=N.N
-> Function Scan on generate_series (cost=N.N..N.N rows=N width=N) (actual time=N.N..N.N rows=N loops=N)
I/O Timings: temp read=N.N write=N.N
+ I/O Timings: shared/local read=N.N
Planning Time: N.N ms
Execution Time: N.N ms
-(6 rows)
+(7 rows)

select explain_filter('explain (analyze, buffers, format json) select count(*) from generate_series(1, 100000)');
explain_filter

I don't see any obvious error in the code, so I'm wondering if it's simply
the result of populating the cache with generate_series() info.

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Amit Kapila 2022-01-19 08:57:51 Re: Skipping logical replication transactions on subscriber side
Previous Message Peter Eisentraut 2022-01-19 08:32:36 Re: SQL:2011 application time