Re: Re: custom hash-based COUNT(DISTINCT) aggregate - unexpectedly high memory consumption - Mailing list pgsql-hackers

From Atri Sharma
Subject Re: Re: custom hash-based COUNT(DISTINCT) aggregate - unexpectedly high memory consumption
Date
Msg-id AD08356B-0EFD-4C70-AFFD-EC39D547F243@gmail.com
Whole thread Raw
In response to Re: Re: custom hash-based COUNT(DISTINCT) aggregate - unexpectedly high memory consumption  (Claudio Freire <klaussfreire@gmail.com>)
List pgsql-hackers

Sent from my iPad

> On 08-Oct-2013, at 10:41, Claudio Freire <klaussfreire@gmail.com> wrote:
>
> On Tue, Oct 8, 2013 at 1:23 AM, Atri Sharma <atri.jiit@gmail.com> wrote:
>>>> Consider the aspects associated with open addressing.Open addressing
>>>> can quickly lead to growth in the main table.Also, chaining is a much
>>>> cleaner way of collision resolution,IMHO.
>>>
>>> What do you mean by "growth in the main table"?
>>
>> Sorry, I should have been more verbose.
>>
>> AFAIK, Open addressing can be slower with a load factor approaching 1
>> as compared to chaining. Also, I feel that implementation of open
>> addressing can be more complicated as we have to deal with deletes
>> etc.
>
>
> Deletes for a hash aggregate?

Yeah, that doesn't apply here.I was just listing out the demerits of open addressing :)

My point is, it is not wise to unnecessarily complicate matters by shifting to open addressing. If we want, we could
lookat changing the data structure used for chaining, but chaining is better for our requirements IMHO. 

Regards,

Atri


pgsql-hackers by date:

Previous
From: Kevin Grittner
Date:
Subject: drop-index-concurrently-1 on master fails at serializable
Next
From: Haribabu kommi
Date:
Subject: Re: Compression of full-page-writes