On Fri, Jan 20, 2023 at 04:40:32PM -0800, Andres Freund wrote: > From 5a458d4584961dedd3f80a07d8faea66e57c5d94 Mon Sep 17 00:00:00 2001 > From: Andres Freund <and...@anarazel.de> > Date: Mon, 16 Jan 2023 11:19:11 -0800 > Subject: [PATCH v8 4/5] wip: report nanoseconds in pg_test_timing
> <para> > - The i7-860 system measured runs the count query in 9.8 ms while > - the <command>EXPLAIN ANALYZE</command> version takes 16.6 ms, each > - processing just over 100,000 rows. That 6.8 ms difference means the > timing > - overhead per row is 68 ns, about twice what pg_test_timing estimated it > - would be. Even that relatively small amount of overhead is making the > fully > - timed count statement take almost 70% longer. On more substantial > queries, > - the timing overhead would be less problematic. > + The i9-9880H system measured shows an execution time of 4.116 ms for the > + <literal>TIMING OFF</literal> query, and 6.965 ms for the > + <literal>TIMING ON</literal>, each processing 100,000 rows. > + > + That 2.849 ms difference means the timing overhead per row is 28 ns. As > + <literal>TIMING ON</literal> measures timestamps twice per row returned by > + an executor node, the overhead is very close to what pg_test_timing > + estimated it would be. > + > + more than what pg_test_timing estimated it would be. Even that relatively > + small amount of overhead is making the fully timed count statement take > + about 60% longer. On more substantial queries, the timing overhead would > + be less problematic. I guess you intend to merge these two paragraphs ?