Re: PATCH: Extending the HyperLogLog API a bit - Mailing list pgsql-hackers

From Peter Geoghegan
Subject Re: PATCH: Extending the HyperLogLog API a bit
Date
Msg-id CAM3SWZSS-kcSDtKLqUSR2ccbeiCWULHA1-n=Z0+mX8PFrz33Hw@mail.gmail.com
Whole thread Raw
In response to PATCH: Extending the HyperLogLog API a bit  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Responses Re: PATCH: Extending the HyperLogLog API a bit  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
List pgsql-hackers
On Thu, Dec 31, 2015 at 12:48 PM, Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> 1) initHyperLogLogError(hyperLogLogState *cState, double error)
>
>    Instead of specifying bwidth (essentially the number of bits used
>    for addressing in the counter), this allows specifying the expected
>    error rate for the counter, which is
>
>       error_rate = 1.04 / sqrt(2^bwidth)
>
>    So for 5% we get bwidth=5, and so on. This makes the API a bit easier
>    the use, because there are pretty much no comments about the meaning
>    of bwidth, and the existing callers simply use 10 without details.

Fair, but you didn't add any better comments!

> 2) freeHyperLogLog(hyperLogLogState *cState)
>
>    I think it's a good idea to provide function "undoing" what init
>    does, i.e. freeing the internal memory etc. Currently that's trivial
>    to do, but perhaps we'll make the structure more complicated in the
>    future (albeit that might be unlikely).

Seems reasonable.

-- 
Peter Geoghegan



pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Re: IMPORT FOREIGN SCHEMA return create foreign table commands are those further filtered in LIMIT and EXCEPT cases?
Next
From: Petr Jelinek
Date:
Subject: pglogical - logical replication contrib module