From: | Robert Haas <rhaas(at)postgresql(dot)org> |
---|---|
To: | pgsql-committers(at)lists(dot)postgresql(dot)org |
Subject: | pgsql: EXPLAIN: Always use two fractional digits for row counts. |
Date: | 2025-02-27 16:46:29 |
Message-ID: | E1tnh1p-0000f3-1L@gemulon.postgresql.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-committers |
EXPLAIN: Always use two fractional digits for row counts.
Commit ddb17e387aa28d61521227377b00f997756b8a27 attempted to avoid
confusing users by displaying digits after the decimal point only when
nloops > 1, since it's impossible to have a fraction row count after a
single iteration. However, this made the regression tests unstable since
parallal queries will have nloops>1 for all nodes below the Gather or
Gather Merge in normal cases, but if the workers don't start in time and
the leader finishes all the work, they will suddenly have nloops==1,
making it unpredictable whether the digits after the decimal point would
be displayed or not. Although 44cbba9a7f51a3888d5087fc94b23614ba2b81f2
seemed to fix the immediate failures, it may still be the case that there
are lower-probability failures elsewhere in the regression tests.
Various fixes are possible here. For example, it has previously been
proposed that we should try to display the digits after the decimal
point only if rows/nloops is an integer, but currently rows is storead
as a float so it's not theoretically an exact quantity -- precision
could be lost in extreme cases. It has also been proposed that we
should try to display the digits after the decimal point only if we're
under some sort of construct that could potentially cause looping
regardless of whether it actually does. While such ideas are not
without merit, this patch adopts the much simpler solution of always
display two decimal digits. If that approach stands up to scrutiny
from the buildfarm and human users, it spares us the trouble of doing
anything more complex; if not, we can reassess.
This commit incidentally reverts 44cbba9a7f51a3888d5087fc94b23614ba2b81f2,
which should no longer be needed.
Author: Robert Haas <robertmhaas(at)gmail(dot)com>
Author: Ilia Evdokimov <ilya(dot)evdokimov(at)tantorlabs(dot)com>
Discussion: http://postgr.es/m/CA+TgmoazzVHn8sFOMFAEwoqBTDxKT45D7mvkyeHgqtoD2cn58Q@mail.gmail.com
Branch
------
master
Details
-------
https://git.postgresql.org/pg/commitdiff/95dbd827f2edc4d10bebd7e840a0bd6782cf69b7
Modified Files
--------------
.../pg_stat_statements/expected/level_tracking.out | 24 +-
contrib/postgres_fdw/expected/postgres_fdw.out | 60 +--
doc/src/sgml/auto-explain.sgml | 10 +-
doc/src/sgml/bloom.sgml | 16 +-
doc/src/sgml/jit.sgml | 8 +-
doc/src/sgml/perform.sgml | 42 +-
doc/src/sgml/planstats.sgml | 24 +-
doc/src/sgml/ref/explain.sgml | 4 +-
doc/src/sgml/rules.sgml | 18 +-
src/backend/commands/explain.c | 34 +-
src/test/regress/expected/brin_multi.out | 72 ++--
src/test/regress/expected/explain.out | 89 ++--
src/test/regress/expected/gin.out | 20 +-
src/test/regress/expected/incremental_sort.out | 20 +-
src/test/regress/expected/matview.out | 8 +-
src/test/regress/expected/memoize.out | 94 ++--
src/test/regress/expected/merge.out | 124 +++---
src/test/regress/expected/misc_functions.out | 60 +--
src/test/regress/expected/partition_prune.out | 480 ++++++++++-----------
src/test/regress/expected/select.out | 6 +-
src/test/regress/expected/select_into.out | 16 +-
src/test/regress/expected/select_parallel.out | 12 +-
src/test/regress/expected/subselect.out | 12 +-
src/test/regress/expected/tidscan.out | 16 +-
src/test/regress/sql/explain.sql | 3 -
25 files changed, 623 insertions(+), 649 deletions(-)
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2025-02-27 18:13:39 | pgsql: Create explain_format.c and move relevant code there. |
Previous Message | Tom Lane | 2025-02-27 16:27:33 | Re: pgsql: Generalize hash and ordering support in amapi |