Thanks to visit codestin.com
Credit goes to postgrespro.com

Re: Tuple sampling - Mailing list pgsql-patches

From Tom Lane
Subject Re: Tuple sampling
Date
Msg-id [email protected]
Whole thread Raw
In response to Tuple sampling  (Manfred Koizar <[email protected]>)
Responses Re: Tuple sampling
Re: Tuple sampling
List pgsql-patches
Manfred Koizar <[email protected]> writes:
> This patch implements the new tuple sampling method as discussed on
> -hackers and -performance a few weeks ago.

Applied with minor editorializations.  AFAICS get_next_S() needs to be
called with the number of tuples already processed, which means you were
off-by-one --- this surely makes only a trivial difference in the
probabilities, but if we are going to use Vitter's algorithm then we may
as well get it right.  Also, I took out the TupleCount typedef and went
back to using doubles for the tuple counts; this is more consistent with
the coding style used elsewhere, and I really doubt that it's any
slower.  (The datatype conversions induced inside get_next_S are likely
to outweigh any savings from counting by ints, on most modern hardware.)
Plus the justification for assuming it couldn't overflow seems weak to
me; the current limitation to 300000 requested sample rows is very
arbitrary and could change anytime.

I was initially convinced that your implementation of Knuth's algorithm
S was all wet, so now there's a bunch of comments explaining why it's
actually correct...

            regards, tom lane

pgsql-patches by date:

Previous
From: "Magnus Hagander"
Date:
Subject: Re: Cancel/Kill backend functions
Next
From: Alvaro Herrera
Date:
Subject: Nested xacts, try 5