On Tue, Jan 19, 2016 at 2:22 PM, Peter Geoghegan wrote:
> I don't have time right now to do a full analysis of whether or not it's
> possible to just fix the bug without doing all that, but I think it
> might not be.
IOW: I think that Hideaki's bug fix might itself be wrong (although I
might be w
On Tue, Jan 19, 2016 at 2:03 PM, Tomas Vondra
wrote:
>
> FWIW I've been considering adding APPROX_COUNT_DISTINCT() aggregate,
> similarly to what other databases (e.g. Vertica) have built-in. Now, that
> would not require the merge too, but we're currently baking support for
> 'combine' functions,
On 01/19/2016 10:54 PM, Peter Geoghegan wrote:
On Tue, Jan 19, 2016 at 9:37 AM, Alvaro Herrera
wrote:
Our transcript seems to predate that bugfix commit, so I assume we need
to apply this to our copy too. Sadly, Hideaki-san commit message isn't
very descriptive.
Fortunately, the function m
On Tue, Jan 19, 2016 at 9:37 AM, Alvaro Herrera
wrote:
> Our transcript seems to predate that bugfix commit, so I assume we need
> to apply this to our copy too. Sadly, Hideaki-san commit message isn't
> very descriptive.
Fortunately, the function mergeHyperLogLog() in our hyperloglog.c
currentl
Robert Haas wrote:
> On Mon, Jan 11, 2016 at 2:22 PM, Alvaro Herrera
> wrote:
> > Tomas Vondra wrote:
> >> Attached is v2 of the patch, adding the comments.
> >
> > Looks pretty reasonable to me. I'm not sure we want to push this ahead
> > of the bloom filter stuff, but it looks ready to commit o
While going over this patch I noticed this commit in HyperLogLog's
upstream:
https://github.com/hideo55/cpp-HyperLogLog/commit/b8cb5e7b856928af15e9535b4b1650f493ba453f
In the first hunk which is what we care about, the author is doing
bit-or of both hash values instead of taking the max value, wh
On Mon, Jan 11, 2016 at 2:22 PM, Alvaro Herrera
wrote:
> Tomas Vondra wrote:
>> Attached is v2 of the patch, adding the comments.
>
> Looks pretty reasonable to me. I'm not sure we want to push this ahead
> of the bloom filter stuff, but it looks ready to commit otherwise.
I'd say go ahead and p
Tomas Vondra wrote:
> Attached is v2 of the patch, adding the comments.
Looks pretty reasonable to me. I'm not sure we want to push this ahead
of the bloom filter stuff, but it looks ready to commit otherwise.
--
Álvaro Herrerahttp://www.2ndQuadrant.com/
PostgreSQL Development,
On 01/01/2016 12:08 AM, Peter Geoghegan wrote:
On Thu, Dec 31, 2015 at 12:48 PM, Tomas Vondra
wrote:
1) initHyperLogLogError(hyperLogLogState *cState, double error)
Instead of specifying bwidth (essentially the number of bits used
for addressing in the counter), this allows specifyin
On Thu, Dec 31, 2015 at 12:48 PM, Tomas Vondra
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,
Meh, of course I forgot to actually attach the patch.
--
Tomas Vondra http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
>From 8f207693faa65e65e8a1e5e894c2ad96ad1f3cea Mon Sep 17 00:00:00 2001
From: Tomas Vondra
Date: Mon, 28 Dec 201
Hi,
while working on the bloom filters for hashjoins, I've started using the
HLL library committed as part of the sorting improvements for 9.5. I
propose adding two more functions to the API, which I think are quite
useful:
1) initHyperLogLogError(hyperLogLogState *cState, double error)
12 matches
Mail list logo