Re: Re: custom hash-based COUNT(DISTINCT) aggregate - unexpectedly high memory consumption

Поиск
Список
Период
Сортировка
От Atri Sharma
Тема Re: Re: custom hash-based COUNT(DISTINCT) aggregate - unexpectedly high memory consumption
Дата
Msg-id AD08356B-0EFD-4C70-AFFD-EC39D547F243@gmail.com
обсуждение исходный текст
Ответ на Re: Re: custom hash-based COUNT(DISTINCT) aggregate - unexpectedly high memory consumption  (Claudio Freire <klaussfreire@gmail.com>)
Список 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 по дате отправления:

Предыдущее
От: Kevin Grittner
Дата:
Сообщение: drop-index-concurrently-1 on master fails at serializable
Следующее
От: Haribabu kommi
Дата:
Сообщение: Re: Compression of full-page-writes