Re: explain analyze rows=%.0f

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>
To: Tom Lane <tgl@sss.pgh.pa.us>
Cc: Simon Riggs <simon@2ndQuadrant.com>, Ron Mayer <rm_pg@cheapcomplexdevices.com>, Euler Taveira de Oliveira <euler@timbira.com>, "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Date: 2009-06-02T14:56:59Z
Lists: pgsql-hackers

...Robert

On Jun 2, 2009, at 10:38 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Robert Haas <robertmhaas@gmail.com> writes:
>> On Jun 2, 2009, at 9:41 AM, Simon Riggs <simon@2ndQuadrant.com>  
>> 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 used in the calc, so the estimates can be checked  
>>> more
>>> thoroughly than is currently possible.
>
>> Bingo.
>
> Uh, the planner's estimate *is* an integer.  What was under discussion
> (I thought) was showing some fractional digits in the case where  
> EXPLAIN
> ANALYZE is outputting a measured row count that is an average over
> multiple loops, and therefore isn't necessarily an integer.  In that
> case the measured value can be considered arbitrarily precise ---  
> though
> I think in practice one or two fractional digits would be plenty.

We're in violent agreement here.

...Robert

Commits

  1. EXPLAIN: Always use two fractional digits for row counts.

  2. Adjust EXPLAIN test case to filter out "Actual Rows" values.

  3. Allow EXPLAIN to indicate fractional rows.

  4. Fix pgbench performance issue induced by commit af35fe501.