MIME-Version: 1.0
References: <CA+TgmoZv8DvmeQHQAX+rkn68id2N+DoUhFZB36d-_w1tyAeqeA@mail.gmail.com>
 <70bc1af0-6910-4f71-84ba-fa02095fe9ba@tantorlabs.com> <CAFY6G8dgp494Xi2+VUUyM2CvuSQ+3nnzWi44gURWbCHjEWW89g@mail.gmail.com>
 <fc28108a-8e7e-4f7d-b8f4-0bcc1581650d@tantorlabs.com> <CA+Tgmobgkh5CW=4Xpejw9nR6Onv8SZh0nnr+=HmNAFyyHZb0eg@mail.gmail.com>
 <3212947.1739306803@sss.pgh.pa.us> <eb73d4e1-4235-41b5-90a8-b0196550f62b@gmail.com>
 <CA+TgmobT9gPQLtw143oGnKVNtaOrTDOy+ZbLfe18MVZ9POjaWg@mail.gmail.com>
 <3365160.1739385615@sss.pgh.pa.us> <0e4c813a-18eb-41e2-8edb-89b78d43c82d@gmail.com>
 <CA+TgmoYzawdq40C5cN==LRPBvQChZ7t5XxH6wv+zMxnyM7LjBQ@mail.gmail.com>
 <e434311c-0f84-4c2b-a10d-ecb67f1ec19d@tantorlabs.com> <CA+TgmobfeePej0uNfbLy0v6jUrB3D9m1Kh+QQ40_-A9KQjkqUw@mail.gmail.com>
 <f428e80d-8607-4a9d-950c-be9600f24904@gmail.com> <01ec86c1-e04b-4cbe-b641-22cae8b87604@tantorlabs.com>
 <CA+TgmobVWYnYDj1HZ--iqeKx+n7zTgtYCar+YfZ0V6wiX-t0Mg@mail.gmail.com>
 <73e2440e-7d8b-4860-974d-931a93326d95@gmail.com> <7ab512ac-eed1-4fc8-9c5f-b42c0b0d313e@tantorlabs.com>
 <CA+TgmoYp1KvG=7L7SjiRjJrXT8kEfH10kSGp54FQd03v19OwvA@mail.gmail.com>
In-Reply-To: <CA+TgmoYp1KvG=7L7SjiRjJrXT8kEfH10kSGp54FQd03v19OwvA@mail.gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
Date: Fri, 21 Feb 2025 16:44:28 -0500
Message-ID: <CA+Tgmoaob_3aNF5S49WFoJs6Rb37rNnd5WH_e9nXAn_jtWWCLQ@mail.gmail.com>
Subject: Re: explain analyze rows=%.0f
To: Ilia Evdokimov <ilya.evdokimov@tantorlabs.com>
Cc: Andrei Lepikhov <lepihov@gmail.com>, pgsql-hackers@lists.postgresql.org, 
	Tom Lane <tgl@sss.pgh.pa.us>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://www.postgresql.org/message-id/CA%2BTgmoaob_3aNF5S49WFoJs6Rb37rNnd5WH_e9nXAn_jtWWCLQ%40mail.gmail.com>
Precedence: bulk

On Fri, Feb 21, 2025 at 4:20=E2=80=AFPM Robert Haas <robertmhaas@gmail.com>=
 wrote:
> So, I've committed v11-0001. I'm not altogether convinced that
> v11-0002 is necessary -- no portion of the documentation that it
> modifies is falsified by the committed patch. Maybe we can just call
> this one done for now and move on?

Well, not quite yet, at least. There are two buildfarm failures since
I committed this. The first is here:

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=3Dconchuela&dt=3D20=
25-02-21%2021%3A22%3A30

diff -U3 /home/pgbf/buildroot/HEAD/pgsql.build/src/test/regress/expected/ex=
plain.out
/home/pgbf/buildroot/HEAD/pgsql.build/src/test/regress/results/explain.out
--- /home/pgbf/buildroot/HEAD/pgsql.build/src/test/regress/expected/explain=
.out
2025-02-21 22:20:39.229225000 +0100
+++ /home/pgbf/buildroot/HEAD/pgsql.build/src/test/regress/results/explain.=
out
2025-02-21 22:22:38.193054000 +0100
@@ -528,7 +528,7 @@
                              "Plan Rows": 0,                +
                              "Plan Width": 0,               +
                              "Total Cost": 0.0,             +
-                             "Actual Rows": 0.0,            +
+                             "Actual Rows": 0,              +
                              "Actual Loops": 0,             +
                              "Startup Cost": 0.0,           +
                              "Async Capable": false,        +
@@ -575,7 +575,7 @@
                      "Plan Rows": 0,                        +
                      "Plan Width": 0,                       +
                      "Total Cost": 0.0,                     +
-                     "Actual Rows": 0.0,                    +
+                     "Actual Rows": 0,                      +
                      "Actual Loops": 0,                     +
                      "Startup Cost": 0.0,                   +
                      "Async Capable": false,                +

I imagine what happened here is that the parallel workers didn't
start, and so nloops was 1 instead of >1, and so we got an integer
output instead of a fractional one. It looks like there's some kind of
JSON-based EXPLAIN filtering happening here, so maybe we should just
also be filtering out the actual rows column? But I fear this will
turn out to be a problem for other parallel-query using tests that
were modified by this commit: it can always happen that the workers
start slowly enough that the leader finishes the whole query before
the worker starts up. Maybe making the number of decimal digits
contingent on nloops wasn't such a hot idea - I think it means that
every parallel query has a small but non-zero probability of producing
different EXPLAIN output in the probably-rare case where the worker
startup is slow.

The other failure is here:

https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=3Dloach&dt=3D2025-0=
2-21%2021%3A25%3A19

This failure seems not to have uploaded any log artifacts, so I'm not
sure how to tell what caused this.

--=20
Robert Haas
EDB: http://www.enterprisedb.com