On Mon, 2009-06-01 at 20:30 -0700, Ron Mayer wrote:
What I'd find strange about 6.67 rows in your example is more that on
the estimated rows side, it seems to imply an unrealistically precise estimate
in the same way that 667 rows would seem unrealistically precise to me.
Maybe rounding to 2
On Jun 2, 2009, at 9:41 AM, Simon Riggs si...@2ndquadrant.com wrote:
On Mon, 2009-06-01 at 20:30 -0700, Ron Mayer wrote:
What I'd find strange about 6.67 rows in your example is more
that on
the estimated rows side, it seems to imply an unrealistically
precise estimate
in the same way
Robert Haas robertmh...@gmail.com writes:
On Jun 2, 2009, at 9:41 AM, Simon Riggs si...@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
...Robert
On Jun 2, 2009, at 10:38 AM, Tom Lane t...@sss.pgh.pa.us wrote:
Robert Haas robertmh...@gmail.com writes:
On Jun 2, 2009, at 9:41 AM, Simon Riggs si...@2ndquadrant.com
wrote:
You're right that the number of significant digits already exceeds
the
true accuracy of the
Euler Taveira de Oliveira wrote:
Robert Haas escreveu:
...EXPLAIN ANALYZE reports the number of rows as an integer... 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
Joshua Tolley eggyk...@gmail.com writes:
On Thu, May 28, 2009 at 11:12:42PM -0400, Robert Haas wrote:
On Thu, May 28, 2009 at 11:00 PM, Euler Taveira de Oliveira
Don't you think is too strange having, for example, 6.67 rows?
No stranger than having it say 7 when it's really not. Actually
On Fri, May 29, 2009 at 1:30 PM, Tom Lane t...@sss.pgh.pa.us wrote:
Joshua Tolley eggyk...@gmail.com writes:
On Thu, May 28, 2009 at 11:12:42PM -0400, Robert Haas wrote:
On Thu, May 28, 2009 at 11:00 PM, Euler Taveira de Oliveira
Don't you think is too strange having, for example, 6.67 rows?
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
Robert Haas escreveu:
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
On Thu, May 28, 2009 at 11:00 PM, Euler Taveira de Oliveira
eu...@timbira.com wrote:
Robert Haas escreveu:
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
On Thu, May 28, 2009 at 11:12:42PM -0400, Robert Haas wrote:
On Thu, May 28, 2009 at 11:00 PM, Euler Taveira de Oliveira
Don't you think is too strange having, for example, 6.67 rows?
No stranger than having it say 7 when it's really not. Actually mine
mostly come out 1 when the real value
11 matches
Mail list logo
