On Tue, May 30, 2006 at 10:01:49AM -0400, Bruce Momjian wrote:
>
> Patch applied. Thanks.

I note Tom made some changes to this patch after it went in. For the
record, it was always my intention that samplecount count the number of
_tuples_ returned while sampling, rather than the number of
_iterations_. I'll admit the comment in the header was wrong.

While my original patch had a small error in the case of multiple
tuples returned, it would've been correctable by counting the actual
number of sample. The way it is now, it will show a bias if the number
of tuples returned increases after the first sampled 50 tuples.
However, my knowledge of statistics isn't good enough to determine if
this is an actual problem or not, since the way it is now will sample
more initialially...

Have a nice day,
--
Martijn van Oosterhout <kleptog@svana.org> http://svana.org/kleptog/
> From each according to his ability. To each according to his ability to litigate.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFEfo1qIB7bNG8LQkwRAhXSAJ96DJkclLH8oxkwYhz2SB 4EFyDLLgCeK7uo
+J/kSeElojU0pxUdNWx1I6I=
=36+6
-----END PGP SIGNATURE-----

Martijn van Oosterhout <kleptog@svana.org> writes:
> I note Tom made some changes to this patch after it went in. For the
> record, it was always my intention that samplecount count the number of
> _tuples_ returned while sampling, rather than the number of
> _iterations_. I'll admit the comment in the header was wrong.

> While my original patch had a small error in the case of multiple
> tuples returned, it would've been correctable by counting the actual
> number of sample. The way it is now, it will show a bias if the number
> of tuples returned increases after the first sampled 50 tuples.

How so? The number of tuples doesn't enter into it at all. What the
code is now assuming is that the time per node iteration is constant.
More importantly, it's subtracting off an overhead estimate that's
measured per iteration. In the math you had before, the overhead was
effectively assumed to be per tuple, which is clearly wrong.

For nodes that return a variable number of tuples, it might be sensible
to presume that the node iteration time is roughly linear in the number
of tuples returned, but I find that debatable. In any case the sampling
overhead is certainly not dependent on how many tuples an iteration
returns.

This is all really moot at the moment, since we have only two kinds of
nodes: those that always return 1 tuple (until done) and those that
return all their tuples in a single iteration. If we ever get into
nodes that return varying numbers of tuples per iteration --- say,
exposing btree's page-at-a-time behavior at the plan node level ---
we'd have to rethink this. But AFAICS we'd need to count both tuples
and iterations to have a model that made any sense at all, so the
extra counter I added is needed anyway.

regards, tom lane

---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend