Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1thWoK-003YLD-TP for pgsql-hackers@arkaria.postgresql.org; Mon, 10 Feb 2025 16:39:04 +0000 Received: from localhost ([127.0.0.1] helo=malur.postgresql.org) by malur.postgresql.org with esmtp (Exim 4.94.2) (envelope-from ) id 1thWoH-002qXY-Ef for pgsql-hackers@arkaria.postgresql.org; Mon, 10 Feb 2025 16:39:01 +0000 Received: from magus.postgresql.org ([2a02:c0:301:0:ffff::29]) by malur.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1thWoH-002qXO-4M for pgsql-hackers@lists.postgresql.org; Mon, 10 Feb 2025 16:39:01 +0000 Received: from forward502a.mail.yandex.net ([2a02:6b8:c0e:500:1:45:d181:d502]) by magus.postgresql.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.96) (envelope-from ) id 1thWoD-0004EV-2g for pgsql-hackers@lists.postgresql.org; Mon, 10 Feb 2025 16:39:00 +0000 Received: from mail-nwsmtp-smtp-production-main-84.iva.yp-c.yandex.net (mail-nwsmtp-smtp-production-main-84.iva.yp-c.yandex.net [IPv6:2a02:6b8:c0c:1f09:0:640:c93e:0]) by forward502a.mail.yandex.net (Yandex) with ESMTPS id C81EB61373; Mon, 10 Feb 2025 19:38:56 +0300 (MSK) Received: by mail-nwsmtp-smtp-production-main-84.iva.yp-c.yandex.net (smtp/Yandex) with ESMTPSA id octCDT3Ora60-g5Xosy9O; Mon, 10 Feb 2025 19:38:55 +0300 X-Yandex-Fwd: 1 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tantorlabs.com; s=mail; t=1739205535; bh=L8SQwHqSdFamWfohr+U4oPpDyJBLG/n2HKNDgRDRG28=; h=From:In-Reply-To:Cc:Date:References:To:Subject:Message-ID; b=tJ4fvYyXEnScc9TyY27DYUmt0/rYZgMlKsFAeLw+8lUeE21WHY0LvlkPDMWagwTgE hUSpo+eBJscRuEwtsuIzVzCPCgO50SvGkxsJncEr+laREq9cGMkdyxNS8t3AC/gwPw HHy3ZvqYsBrVvFEdid9s7vQrGF1fwg2MJUEYWmJA= Authentication-Results: mail-nwsmtp-smtp-production-main-84.iva.yp-c.yandex.net; dkim=pass header.i=@tantorlabs.com Message-ID: <73559119-65b0-4989-b69c-53c81c65de79@tantorlabs.com> Date: Mon, 10 Feb 2025 19:38:50 +0300 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: explain analyze rows=%.0f To: Matheus Alcantara Cc: Guillaume Lelarge , Daniel Gustafsson , Ibrar Ahmed , "Gregory Stark (as CFM)" , Tom Lane , Robert Haas , Amit Kapila , Justin Pryzby , Peter Geoghegan , vignesh C , "David G. Johnston" , pgsql-hackers@lists.postgresql.org References: <2954811.1667711530@sss.pgh.pa.us> <55695d15-c738-4401-8883-58bc855c9b03@tantorlabs.com> <58bb3a5b-c92a-408c-b02a-f47aedc1c0e2@tantorlabs.com> <70bc1af0-6910-4f71-84ba-fa02095fe9ba@tantorlabs.com> Content-Language: en-US From: Ilia Evdokimov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit List-Id: List-Help: List-Subscribe: List-Post: List-Owner: List-Archive: Archived-At: Precedence: bulk On 10.02.2025 18:32, Matheus Alcantara wrote: > Thanks for the new patch version. > > -- v7-0001-Clarify-display-of-rows-and-loops-as-decimal-fraction.patch >> + if (nloops > 1 && planstate->instrument->ntuples < nloops) >> + appendStringInfo(es->str," rows=%.2f loops=%.2f)", rows, nloops); >> > Sorry, but why do the 'loops' need to be changed? IIUC the issue is > only with the > rows field? When testing this patch I got some results similar with this: > Index Scan using t_a_idx on t (cost=0.14..0.28 rows=1 width=8) > (actual time=0.049..0.049 rows=0.50 loops=2.00) The only reason I added this was to make it clear to the user that loops > 1, along with the 'rows' value. If no one finds it useful and it only raises more questions, I can remove it. > >> When the total number of returned tuples is less than the number of >> loops currently shows 'rows = 0'. This can mislead users into thinking >> that no rows were returned at all, even though some might have appeared >> occasionally. >> > I think that this can happen when the returned rows and the loops are small > enough to result in a 'row' value like 0.00045? I'm not sure if we have > "bigger" values (e.g 1074(ntuples) / 117(nloops) which would result in 9.17 > rows) this would also be true, what do you think? If you could provide > an example of this case would be great! Based on what was discussed earlier in the thread, there are cases with large loops [0]. However, I believe it's better not to display average rows with excessively long digits or in scientific notation. And, of course, I agree with you regarding small values. I think we should also add a check to ensure that the total rows is actually greater than zero. When the total rows is zero, we could simply display it as an integer without decimals. It could help users average rows is very small but not zero. What do you think about this approach? > > - executing the index scans on tenk2. > + executing the index scans on tenk2. If a subplan node > + is executed multiple times and the average number of rows is less than one, > + the rows and loops values are shown as a > decimal fraction > + (with two digits after the decimal point) to indicate that some rows > + were actually processed rather than simply rounding down to zero. > > * I think that it would be good to mention what a 'row' value in > decimal means. For > example, if its says "0.1 rows" the user should assume that typically 0 rows > will be returned but sometimes it can return 1 or more. > > * There are more spaces than necessary before "If a subplan node ..." > > * Maybe wrap 'rows' with ? > I agree with the last two points. As for the first one—maybe we could simply state that the average rows value can be decimal, especially for very small values? [0]: https://www.postgresql.org/message-id/a9393107-6bb9-c835-50b7-c0f453a514b8%40postgrespro.ru -- Best regards, Ilia Evdokimov, Tantor Labs LLC.