On Wed, Jan 19, 2022 at 5:52 PM Julien Rouhaud <rjuju...@gmail.com> wrote: > > 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.
Thank you for reporting. You're right, the regression test with track_io_timing = on is not entirely stable because we may read catalog data during planning time, resulting in an additional line in the EXPLAIN output. I've removed the regression tests. I've attached updated patches. I've included an improvement of pg_stat_statement support to support temp I/O timing. Regards, -- Masahiko Sawada EDB: https://www.enterprisedb.com/
v3-0002-pg_stat_statements-Track-I-O-timing-for-temp-bloc.patch
Description: Binary data
v3-0001-Track-I-O-timing-for-temp-buffers.patch
Description: Binary data
