Re: explain analyze rows=%.0f

On 31.03.2025 23:59, Ilia Evdokimov wrote: We definitely shouldn’t remove the row counts < 1 check, since there are many places in the planner where we divide by rows. This mechanism was added specifically to prevent division by zero. Also, allowing rows estimates below 1 can sometimes make

Re: explain analyze rows=%.0f

On 3/31/25 19:35, Robert Haas wrote: But why isn't it just as valuable to have two decimal places for the estimate? I theorize that the cases that are really a problem here are those where the row count estimate is between 0 and 1 per row, and rounding to an integer loses all precision. Issues I'

Re: explain analyze rows=%.0f

On 31.03.2025 22:09, Robert Haas wrote: Oh, right. I've never really understood why we round off to integers, but the fact that we don't allow row counts < 1 feels like something pretty important. My intuition is that it probably helps a lot more than it hurts, too. We definitely shouldn’t re

Re: explain analyze rows=%.0f

On Mon, Mar 31, 2025 at 1:49 PM Tom Lane wrote: > Robert Haas writes: > > But why isn't it just as valuable to have two decimal places for the > > estimate? I theorize that the cases that are really a problem here are > > those where the row count estimate is between 0 and 1 per row, and > > roun

Re: explain analyze rows=%.0f

Robert Haas writes: > But why isn't it just as valuable to have two decimal places for the > estimate? I theorize that the cases that are really a problem here are > those where the row count estimate is between 0 and 1 per row, and > rounding to an integer loses all precision. Currently, the pla

Re: explain analyze rows=%.0f

On Tue, Mar 11, 2025 at 5:58 AM Ilia Evdokimov wrote: > In the stats_ext regression test, there is a function > check_estimated_rows that returns actual rows as an integer. Currently, > none of the test cases produce a non-zero fractional part in actual rows. > > The question is: should this funct

Re: explain analyze rows=%.0f

Hi, In the stats_ext regression test, there is a function check_estimated_rows that returns actual rows as an integer. Currently, none of the test cases produce a non-zero fractional part in actual rows. The question is: should this function be modified to return a fractional number instead

Re: explain analyze rows=%.0f

On Thu, Mar 6, 2025 at 4:18 PM Alena Rybakina wrote: > To be honest, I initially took it as the total number of tuples and > couldn't figure out for myself how to interpret the result - 0 tuples or > 1 tuple in the end. Maybe it wasn't quite correct to perceive it that > way, but Matthias's explan

Re: explain analyze rows=%.0f

On 06.03.2025 17:13, Robert Haas wrote: On Thu, Mar 6, 2025 at 8:30 AM Matthias van de Meent wrote: On Thu, 6 Mar 2025 at 14:18, Alena Rybakina wrote: Hi! I got a query plan with a strange number of rows. Could you please help me understand it? To be honest I can't understand why 0.50 number

Re: explain analyze rows=%.0f

On 06.03.2025 16:30, Matthias van de Meent wrote: On Thu, 6 Mar 2025 at 14:18, Alena Rybakina wrote: Hi! I got a query plan with a strange number of rows. Could you please help me understand it? To be honest I can't understand why 0.50 number of rows here? Because the scan matched only ~(500

Re: explain analyze rows=%.0f

On Thu, Mar 6, 2025 at 8:30 AM Matthias van de Meent wrote: > On Thu, 6 Mar 2025 at 14:18, Alena Rybakina wrote: > > > > Hi! I got a query plan with a strange number of rows. Could you please > > help me understand it? > > > > To be honest I can't understand why 0.50 number of rows here? > > Beca

Re: explain analyze rows=%.0f

Hi! I got a query plan with a strange number of rows. Could you please help me understand it? create temp table ta (id int primary key, val int); create temp table tb (id int primary key, aval int); create temp table tc (id int primary key, aid int); insert into ta select id, id from generate_se

Re: explain analyze rows=%.0f

On Thu, 6 Mar 2025 at 14:18, Alena Rybakina wrote: > > Hi! I got a query plan with a strange number of rows. Could you please > help me understand it? > > To be honest I can't understand why 0.50 number of rows here? Because the scan matched only ~(500 rows over 999 iterations = 500/999 ~=) 0.50

Re: explain analyze rows=%.0f

On 27.02.2025 19:51, Robert Haas wrote: On Mon, Feb 24, 2025 at 2:16 PM Robert Haas wrote: On Mon, Feb 24, 2025 at 12:12 PM Ilia Evdokimov wrote: If no one is concerned about rows being a non-integer, then I support this, as it's quite strange for the average rows to be an integer only for

Re: explain analyze rows=%.0f

On Mon, Feb 24, 2025 at 2:16 PM Robert Haas wrote: > On Mon, Feb 24, 2025 at 12:12 PM Ilia Evdokimov > wrote: > > If no one is concerned about rows being a non-integer, then I support > > this, as it's quite strange for the average rows to be an integer only > > for me. If we go with this approac

Re: explain analyze rows=%.0f

On Mon, Feb 24, 2025 at 12:12 PM Ilia Evdokimov wrote: > If no one is concerned about rows being a non-integer, then I support > this, as it's quite strange for the average rows to be an integer only > for me. If we go with this approach, we should also update all examples > in the documentation a

Re: explain analyze rows=%.0f

On 24.02.2025 19:20, Robert Haas wrote: On Fri, Feb 21, 2025 at 10:00 PM Robert Haas wrote: I guess we could do that, but how about just always displaying two decimal places? I feel like you're really worried that people will be confused if the row count is not an integer, but I'm not sure any

Re: explain analyze rows=%.0f

On 22.02.2025 00:20, Robert Haas 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? Not quite. If no one

Re: explain analyze rows=%.0f

On Fri, Feb 21, 2025 at 9:11 PM Tom Lane wrote: > I apologize if I ruffled your feathers. But the buildfarm is a shared > resource and it doesn't do to leave it significantly broken over a > weekend, which I feared you might be about to do. Committing stuff > at 4PM on a Friday is perhaps not th

Re: explain analyze rows=%.0f

Hi, On 2025-02-21 21:11:07 -0500, Tom Lane wrote: > Robert Haas writes: > > Yeah, I pushed an attempt at a band-aid fix. Hopefully that will make > > it clear whether there are other problems and how bad they are. It > > looks like the XversionUpgrade tests are not this commit's fault. > > They

Re: explain analyze rows=%.0f

Robert Haas writes: > Yeah, I pushed an attempt at a band-aid fix. Hopefully that will make > it clear whether there are other problems and how bad they are. It > looks like the XversionUpgrade tests are not this commit's fault. They are not, they're Jeff's problem. I apologize if I ruffled your

Re: explain analyze rows=%.0f

On Fri, Feb 21, 2025 at 7:04 PM Tom Lane wrote: > Sounds plausible. I note that this run: > > https://buildfarm.postgresql.org/cgi-bin/show_log.pl?nm=skimmer&dt=2025-02-21%2023%3A00%3A10 > > got through a couple of iterations of the core tests before failing, > showing that it's not 100% reproduc

Re: explain analyze rows=%.0f

Robert Haas writes: > Well, not quite yet, at least. There are two buildfarm failures since > I committed this. The first is here: A very significant fraction of the buildfarm is now pink. If you don't have a fix pretty nearly ready, please revert. > I imagine what happened here is that the para

Re: explain analyze rows=%.0f

On Wed, Feb 19, 2025 at 9:01 AM Ilia Evdokimov wrote: > The idea of indicating to the user that different iterations produced > varying numbers of rows is quite reasonable. Most likely, this would > require adding a new boolean field to the Instrumentation structure, > which would track this infor

Re: explain analyze rows=%.0f

On Fri, Feb 21, 2025 at 4:20 PM Robert Haas 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,

Re: explain analyze rows=%.0f

On 19/2/2025 15:01, Ilia Evdokimov wrote: If we want to convey this information more clearly, we should consider a more explicit approach. For example, instead of using a fractional value, we could display the minimum and maximum row counts observed during execution (e.g.,rows=10..20, formattin

Re: explain analyze rows=%.0f

On 18.02.2025 23:55, Andrei Lepikhov wrote: On 17/2/2025 15:19, Robert Haas wrote: On Mon, Feb 17, 2025 at 3:08 AM Ilia Evdokimov if (nloops > 1) Instead of: if (nloops > 1 && rows_is_fractonal) I don't think it's really safe to just cast a double back to int64. In practice, the number of t

Re: explain analyze rows=%.0f

On 17/2/2025 15:19, Robert Haas wrote: On Mon, Feb 17, 2025 at 3:08 AM Ilia Evdokimov if (nloops > 1) Instead of: if (nloops > 1 && rows_is_fractonal) I don't think it's really safe to just cast a double back to int64. In practice, the number of tuples should never be large enough to overflow

Re: explain analyze rows=%.0f

On 17.02.2025 17:19, Robert Haas wrote: On Mon, Feb 17, 2025 at 3:08 AM Ilia Evdokimov wrote: You're right—floor shouldn't be used since it behaves differently across platforms, as Tom also pointed out earlier. I like the idea of using %, but since the compiler doesn't allow this operation wit

Re: explain analyze rows=%.0f

On Mon, Feb 17, 2025 at 3:08 AM Ilia Evdokimov wrote: > You're right—floor shouldn't be used since it behaves differently across > platforms, as Tom also pointed out earlier. I like the idea of using %, > but since the compiler doesn't allow this operation with double, we need > to cast it to int6

Re: explain analyze rows=%.0f

On 15.02.2025 11:46, Andrei Lepikhov wrote: On 13/2/2025 21:42, Robert Haas wrote: On Thu, Feb 13, 2025 at 4:05 AM Ilia Evdokimov wrote: 1. Documentation (v9-0001-Clarify-display-of-rows-as-decimal-fractions-DOC.patch) One thing that bothers me is that the documentation explains how to com

Re: explain analyze rows=%.0f

On 13/2/2025 21:42, Robert Haas wrote: On Thu, Feb 13, 2025 at 4:05 AM Ilia Evdokimov wrote: 1. Documentation (v9-0001-Clarify-display-of-rows-as-decimal-fractions-DOC.patch) One thing that bothers me is that the documentation explains how to compute total time, but it does not clarify how t

Re: explain analyze rows=%.0f

On Thu, Feb 13, 2025 at 4:05 AM Ilia Evdokimov wrote: > 1. Documentation > (v9-0001-Clarify-display-of-rows-as-decimal-fractions-DOC.patch) > > One thing that bothers me is that the documentation explains how to compute > total time, but it does not clarify how to compute total rows. Maybe this

Re: explain analyze rows=%.0f

On 12.02.2025 22:56, Robert Haas wrote: On Wed, Feb 12, 2025 at 2:55 PM Andrei Lepikhov wrote: On 13/2/2025 01:40, Tom Lane wrote: I was idly speculating yesterday about letting the Ryu code print the division result, so that we get a variable number of digits. Realistically, that'd probably

Re: explain analyze rows=%.0f

On Wed, Feb 12, 2025 at 2:55 PM Andrei Lepikhov wrote: > On 13/2/2025 01:40, Tom Lane wrote: > > I was idly speculating yesterday about letting the Ryu code print > > the division result, so that we get a variable number of digits. > > Realistically, that'd probably result in many cases in more di

Re: explain analyze rows=%.0f

On 13/2/2025 01:40, Tom Lane wrote: I was idly speculating yesterday about letting the Ryu code print the division result, so that we get a variable number of digits. Realistically, that'd probably result in many cases in more digits than anybody wants, so it's not a serious proposal. I'm cool w

Re: explain analyze rows=%.0f

Robert Haas writes: > I agree that showing 2 digits after the decimal point in all cases is > not ideal, but I suggest that we take a practical approach. Figuring > out dynamically what number of decimal digits to display in each case > sounds complicated and we may spend a bunch of time arguing a

Re: explain analyze rows=%.0f

On Wed, Feb 12, 2025 at 5:10 AM Ilia Evdokimov wrote: > I think the idea of keeping two significant digits after the decimal > point is quite reasonable. The thing is, rows=0.01 or something > similar can only occur when loops is quite large. If we show the order > of magnitude in rows, it wil

Re: explain analyze rows=%.0f

On Tue, Feb 11, 2025 at 2:18 PM Ilia Evdokimov wrote: > With such example, it's hard to disagree with it. This would really add > valuable information. Taking all opinions into account, I have updated > the patch v8. I have also included a check for the case where there are > only zeros after the

Re: explain analyze rows=%.0f

On 12.02.2025 11:54, Andrei Lepikhov wrote: May we agree on a more general formula to print at least two meaningful digits if we have a fractional part? Examples: - actual rows = 2, nloops = 2 -> rows = 1 - actual rows = 9, nloops = 5 -> rows = 1.8 - actual rows = 101, nloops = 100 -> rows =

Re: explain analyze rows=%.0f

On 12/2/2025 03:46, Tom Lane wrote: Robert Haas writes: On Tue, Feb 11, 2025 at 12:14 PM Andrei Lepikhov wrote: I support the idea in general, but I believe it should be expanded to cover all cases of parameterised plan nodes. Each rescan iteration may produce a different number of tuples, an

Re: explain analyze rows=%.0f

Robert Haas writes: > On Tue, Feb 11, 2025 at 12:14 PM Andrei Lepikhov wrote: >> I support the idea in general, but I believe it should be expanded to >> cover all cases of parameterised plan nodes. Each rescan iteration may >> produce a different number of tuples, and rounding can obscure import

Re: explain analyze rows=%.0f

On 12/2/2025 00:41, Robert Haas wrote: On Tue, Feb 11, 2025 at 12:14 PM Andrei Lepikhov wrote: Moreover, switching to a floating-point type for row explanations in each parameterised node would provide a more comprehensive view and add valuable information about the parameterisation of the node

Re: explain analyze rows=%.0f

On 11.02.2025 20:41, Robert Haas wrote: On Tue, Feb 11, 2025 at 12:14 PM Andrei Lepikhov wrote: I support the idea in general, but I believe it should be expanded to cover all cases of parameterised plan nodes. Each rescan iteration may produce a different number of tuples, and rounding can ob

Re: explain analyze rows=%.0f

Hi! Thank you for your valuable work on this! On 11.02.2025 22:18, Ilia Evdokimov wrote: On 11.02.2025 20:41, Robert Haas wrote: On Tue, Feb 11, 2025 at 12:14 PM Andrei Lepikhov wrote: I support the idea in general, but I believe it should be expanded to cover all cases of parameterised plan

Re: explain analyze rows=%.0f

On Tue, Feb 11, 2025 at 12:14 PM Andrei Lepikhov wrote: > I support the idea in general, but I believe it should be expanded to > cover all cases of parameterised plan nodes. Each rescan iteration may > produce a different number of tuples, and rounding can obscure important > data. > > For exampl

Re: explain analyze rows=%.0f

On 8/2/2025 04:28, Ilia Evdokimov wrote: On 08.02.2025 00:01, Matheus Alcantara wrote: Just for reference I'm trying to apply based on commit fb056564ec5. You are right, because two commits were appeared after creating v6-patch on partition_prune.out and patch v6 must not have applied on master

Re: explain analyze rows=%.0f

Em seg., 10 de fev. de 2025 às 18:14, Ilia Evdokimov escreveu: > Sorry for missing your question earlier. If you notice in the code above, the > variable(average) 'rows' is defined as: > > double rows = planstate->instrument->ntuples / nloops; > > This represents the total rows divided by the num

Re: explain analyze rows=%.0f

On 10.02.2025 23:43, Matheus Alcantara wrote: 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 h

Re: explain analyze rows=%.0f

Em seg., 10 de fev. de 2025 às 13:38, Ilia Evdokimov escreveu: > > -- 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)", >

Re: explain analyze rows=%.0f

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=%.

Re: explain analyze rows=%.0f

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

Re: explain analyze rows=%.0f

On 08.02.2025 00:01, Matheus Alcantara wrote: Em sex., 7 de fev. de 2025 às 17:41, Ilia Evdokimov escreveu: Strange, I don't have any problems to apply it on master. postgres$ git branch * master postgres$ git pull Already up to date. postgres$ git apply v6-0001-Clarify-display-of

Re: explain analyze rows=%.0f

Em sex., 7 de fev. de 2025 às 17:41, Ilia Evdokimov escreveu: > Strange, I don't have any problems to apply it on master. > > postgres$ git branch > * master > postgres$ git pull > Already up to date. > postgres$ git apply > v6-0001-Clarify-display-of-rows-and-loops-as-decimal-fraction.p

Re: explain analyze rows=%.0f

On 07.02.2025 22:59, Matheus Alcantara wrote: Hi v6 is not applying on master, could you please rebase? git apply v6-0001-Clarify-display-of-rows-and-loops-as-decimal-fraction.patch error: patch failed: src/test/regress/expected/partition_prune.out:3041 error: src/test/regress/expected/partiti

Re: explain analyze rows=%.0f

Hi Em seg., 13 de jan. de 2025 às 17:18, Ilia Evdokimov escreveu: > I guess, it's not ideal to modify the existing example in the documentation > of the v5 patch because readers wouldn't immediately understand why decimal > fractions appear there. Instead, I'll add a brief note in the documenta

Re: explain analyze rows=%.0f

On 11.01.2025 14:10, Ilia Evdokimov wrote: On 11.01.2025 12:15, Guillaume Lelarge wrote: Thanks for your patch, this looks like a very interesting feature that I'd like to see in a future release. It did a quick run: patch OK, make OK, make install OK, but make check fails quite a lot o

Re: explain analyze rows=%.0f

On 11.01.2025 17:02, Guillaume Lelarge wrote: Le sam. 11 janv. 2025 à 12:10, Ilia Evdokimov a écrit : On 11.01.2025 12:15, Guillaume Lelarge wrote: Thanks for your patch, this looks like a very interesting feature that I'd like to see in a future release. It did a quick r

Re: explain analyze rows=%.0f

Le sam. 11 janv. 2025 à 12:10, Ilia Evdokimov a écrit : > > On 11.01.2025 12:15, Guillaume Lelarge wrote: > > > > Thanks for your patch, this looks like a very interesting feature that I'd > like to see in a future release. > > It did a quick run: patch OK, make OK, make install OK, but make chec

Re: explain analyze rows=%.0f

On 11.01.2025 12:15, Guillaume Lelarge wrote: Thanks for your patch, this looks like a very interesting feature that I'd like to see in a future release. It did a quick run: patch OK, make OK, make install OK, but make check fails quite a lot on partition_prune.sql. I guess it would need

Re: explain analyze rows=%.0f

Hello, Le jeu. 12 déc. 2024 à 12:57, Ilia Evdokimov a écrit : > > On 01.08.2023 23:29, Daniel Gustafsson wrote: > >> On 3 Jul 2023, at 18:34, Daniel Gustafsson wrote: > >> > >>> On 8 Jun 2023, at 19:49, Ibrar Ahmed wrote: > >>> On Mon, Mar 20, 2023 at 7:56 PM Gregory Stark (as CFM) < > stark..

Re: explain analyze rows=%.0f

On 01.08.2023 23:29, Daniel Gustafsson wrote: On 3 Jul 2023, at 18:34, Daniel Gustafsson wrote: On 8 Jun 2023, at 19:49, Ibrar Ahmed wrote: On Mon, Mar 20, 2023 at 7:56 PM Gregory Stark (as CFM) mailto:stark@gmail.com>> wrote: This patch was marked Returned with Feedback and then later W

Re: explain analyze rows=%.0f

> On 3 Jul 2023, at 18:34, Daniel Gustafsson wrote: > >> On 8 Jun 2023, at 19:49, Ibrar Ahmed wrote: >> On Mon, Mar 20, 2023 at 7:56 PM Gregory Stark (as CFM) > > wrote: > >> This patch was marked Returned with Feedback and then later Waiting on >> Author. And it has

Re: explain analyze rows=%.0f

> On 8 Jun 2023, at 19:49, Ibrar Ahmed wrote: > On Mon, Mar 20, 2023 at 7:56 PM Gregory Stark (as CFM) > wrote: > This patch was marked Returned with Feedback and then later Waiting on > Author. And it hasn't had any updates since January. What is the state > on this

Re: explain analyze rows=%.0f

On Mon, Mar 20, 2023 at 7:56 PM Gregory Stark (as CFM) wrote: > On Wed, 4 Jan 2023 at 10:05, Ibrar Ahmed wrote: > > > > Thanks, I have modified everything as suggested, except one point > > > > > Don't use variable format strings. They're hard to read and they > > > probably defeat compile-time

Re: explain analyze rows=%.0f

On Wed, 4 Jan 2023 at 10:05, Ibrar Ahmed wrote: > > Thanks, I have modified everything as suggested, except one point > > > Don't use variable format strings. They're hard to read and they > > probably defeat compile-time checks that the arguments match the > > format string. You could use a "*" f

Re: explain analyze rows=%.0f

On Sun, Nov 6, 2022 at 10:12 AM Tom Lane wrote: > Robert Haas writes: > > On Fri, Jul 22, 2022 at 6:47 AM Amit Kapila > wr= > ote: > >> I feel the discussion has slightly deviated which makes it unclear > >> whether this patch is required or not? > > > My opinion is that showing some fractional

Re: explain analyze rows=%.0f

On 22/7/2022 16:47, Amit Kapila wrote: I feel the discussion has slightly deviated which makes it unclear whether this patch is required or not? After quick review I want to express my thoughts. At first, We have been waiting for this feature for years. Often clients give an explain to us wher

Re: explain analyze rows=%.0f

Robert Haas writes: > On Fri, Jul 22, 2022 at 6:47 AM Amit Kapila wr= ote: >> I feel the discussion has slightly deviated which makes it unclear >> whether this patch is required or not? > My opinion is that showing some fractional digits at least when > loops>1 would be better than what we have

Re: explain analyze rows=%.0f

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:not tested The previous review was incorrectly posted. Updating the pat.ch revie

Re: explain analyze rows=%.0f

The following review has been posted through the commitfest application: make installcheck-world: tested, failed Implements feature: tested, failed Spec compliant: not tested Documentation:not tested LGTM

Re: explain analyze rows=%.0f

The following review has been posted through the commitfest application: make installcheck-world: tested, passed Implements feature: tested, passed Spec compliant: not tested Documentation:not tested Verified patch 'explain_float_row_v3.patch' on master & REL_15_STABLE

Re: explain analyze rows=%.0f

On Fri, Jul 22, 2022 at 6:47 AM Amit Kapila wrote: > I feel the discussion has slightly deviated which makes it unclear > whether this patch is required or not? My opinion is that showing some fractional digits at least when loops>1 would be better than what we have now. It might not be the best

Re: explain analyze rows=%.0f

On Fri, Jul 8, 2022 at 3:50 AM Justin Pryzby wrote: > > On Thu, Jul 07, 2022 at 04:21:37PM -0400, Robert Haas wrote: > > I mean, what I really want here if I'm honest is to not have the > > system divide the number of rows by the loop count. And it sort of > > sounds like maybe that's what you wan

Re: explain analyze rows=%.0f

On Thu, Jul 7, 2022 at 10:53 PM Greg Stark wrote: > > - -> Parallel Seq Scan on tenk1 (actual rows=1960 > loops=50) > > + -> Parallel Seq Scan on tenk1 (actual rows=1960.00 > > At the not inconsiderable risk of bike-shedding > > I'm wondering if printing somethin

Re: explain analyze rows=%.0f

On Thu, Jul 7, 2022 at 3:14 PM vignesh C wrote: > On Thu, Jun 23, 2022 at 2:25 AM Ibrar Ahmed wrote: > > > > > > > > On Thu, Jun 23, 2022 at 1:04 AM David G. Johnston < > david.g.johns...@gmail.com> wrote: > >> > >> On Wed, Jun 22, 2022 at 12:11 PM Ibrar Ahmed > wrote: > >>> > >>> On Thu, Jun 2

Re: explain analyze rows=%.0f

On Thu, Jul 7, 2022 at 2:41 PM Amit Kapila wrote: > On Thu, Jun 23, 2022 at 2:25 AM Ibrar Ahmed wrote: > > > > On Thu, Jun 23, 2022 at 1:04 AM David G. Johnston < > david.g.johns...@gmail.com> wrote: > >> > >> - WRITE_FLOAT_FIELD(rows, "%.0f"); > >> + WRITE_FLOAT_FIELD(rows, "%.2f"); > >> > >> T

Re: explain analyze rows=%.0f

On Thu, Jul 07, 2022 at 04:21:37PM -0400, Robert Haas wrote: > I mean, what I really want here if I'm honest is to not have the > system divide the number of rows by the loop count. And it sort of > sounds like maybe that's what you want, too. You want to know whether > the loop count is actually z

Re: explain analyze rows=%.0f

On Thu, Jul 7, 2022 at 1:21 PM Robert Haas wrote: > Nested Loop (actual time=TIME FOR THIS AND ALL CHILDREN rows=THE REAL > ROW COUNT loops=1) > -> Seq Scan on something (actual time=THE TIME IT REALLY TOOK rows=THE > REAL ROW COUNT loops=1) > -> Index Scan using someidx on somethingelse (actual t

Re: explain analyze rows=%.0f

On Thu, Jul 7, 2022 at 1:53 PM Greg Stark wrote: > > - -> Parallel Seq Scan on tenk1 (actual rows=1960 loops=50) > > + -> Parallel Seq Scan on tenk1 (actual rows=1960.00 > > At the not inconsiderable risk of bike-shedding > > I'm wondering if printing something li

Re: explain analyze rows=%.0f

> - -> Parallel Seq Scan on tenk1 (actual rows=1960 loops=50) > + -> Parallel Seq Scan on tenk1 (actual rows=1960.00 At the not inconsiderable risk of bike-shedding I'm wondering if printing something like 0.00 will be somewhat deceptive when the real value is no

Re: explain analyze rows=%.0f

On Thu, Jun 23, 2022 at 2:25 AM Ibrar Ahmed wrote: > > > > On Thu, Jun 23, 2022 at 1:04 AM David G. Johnston > wrote: >> >> On Wed, Jun 22, 2022 at 12:11 PM Ibrar Ahmed wrote: >>> >>> On Thu, Jun 23, 2022 at 12:01 AM Tom Lane wrote: Robert Haas writes: > On Jun 2, 2009, at 9:41

Re: explain analyze rows=%.0f

On Thu, Jun 23, 2022 at 2:25 AM Ibrar Ahmed wrote: > > On Thu, Jun 23, 2022 at 1:04 AM David G. Johnston > wrote: >> >> - WRITE_FLOAT_FIELD(rows, "%.0f"); >> + WRITE_FLOAT_FIELD(rows, "%.2f"); >> >> This one looks suspicious, though I haven't dug into the code to see exactly >> what all is bein

Re: explain analyze rows=%.0f

On Thu, Jun 23, 2022 at 1:04 AM David G. Johnston < david.g.johns...@gmail.com> wrote: > On Wed, Jun 22, 2022 at 12:11 PM Ibrar Ahmed > wrote: > >> On Thu, Jun 23, 2022 at 12:01 AM Tom Lane wrote: >> >>> Robert Haas writes: >>> > On Jun 2, 2009, at 9:41 AM, Simon Riggs wrote: >>> >> You're rig

Re: explain analyze rows=%.0f

On Wed, Jun 22, 2022 at 12:11 PM Ibrar Ahmed wrote: > On Thu, Jun 23, 2022 at 12:01 AM Tom Lane wrote: > >> Robert Haas writes: >> > On Jun 2, 2009, at 9:41 AM, Simon Riggs wrote: >> >> You're right that the number of significant digits already exceeds the >> >> true accuracy of the computatio

Re: explain analyze rows=%.0f

On Thu, Jun 23, 2022 at 12:01 AM Tom Lane wrote: > Robert Haas writes: > > On Jun 2, 2009, at 9:41 AM, Simon Riggs wrote: > >> You're right that the number of significant digits already exceeds the > >> true accuracy of the computation. I think what Robert wants to see is > >> the exact value u