DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:date:message-id:subject:from:to:content-type
	:content-transfer-encoding;
	b=ryhmpEhf1DB5pqvB6P8wjYT32HmHqKKTN27iWuNZW6ank5DAsGcQ61DhD8NIVyhWF6
	h6wlWWVRxCJg9xWzmC8/M6wOLCnRL3ZQcfUQ5BbB0apSHeKjw/NrociKjOw+V1yuvLi2
	1gEQQ3fK1Nk5NWmhHyqdKRfc0D6rWMjUgnY6o=
MIME-Version: 1.0
Date: Thu, 28 May 2009 21:30:14 -0400
Message-ID: <603c8f070905281830g2e5419c4xad2946d149e21f9d@mail.gmail.com>
Subject: explain analyze rows=%.0f
From: Robert Haas <robertmhaas@gmail.com>
To: "pgsql-hackers@postgresql.org" <pgsql-hackers@postgresql.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

I have always assumed that there is some very good reason why EXPLAIN
ANALYZE reports the number of rows as an integer rather than a
floating point value, but in reading explain.c it seems that the
reason is just that we decided to round to zero decimal places.  Any
chance we could reconsider this decision?  I often find myself wanting
to know the value that is here called ntuples, but rounding
ntuples/nloops off to the nearest integer loses too much precision.

(Before someone mentions it, yes that would be a good thing to include
in XML-formatted explain output.  But I don't see that including a
couple of decimal places would hurt the text output format either.)

...Robert