Re: PATCH: decreasing memory needlessly consumed by array_agg

Поиск
Список
Период
Сортировка
От Jeff Davis
Тема Re: PATCH: decreasing memory needlessly consumed by array_agg
Дата
Msg-id CAMp0ubccbTmQwuyb9dUeQLr+fTDKtOJk0ceCaJg7SBMYJbVTkg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: PATCH: decreasing memory needlessly consumed by array_agg  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: PATCH: decreasing memory needlessly consumed by array_agg  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Re: PATCH: decreasing memory needlessly consumed by array_agg  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Jan 20, 2015 at 6:44 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Jeff Davis <pgsql@j-davis.com> writes:
>> Tom (tgl),
>> Is my reasoning above acceptable?
>
> Uh, sorry, I've not been paying any attention to this thread for awhile.
> What's the remaining questions at issue?

This patch is trying to improve the array_agg case where there are
many arrays being constructed simultaneously, such as in HashAgg. You
strongly suggested that a commitable patch would differentiate between
the grouped and ungrouped cases (or perhaps you meant differentiate
between HashAgg and sorted aggregation?). Tomas's current patch does
not do so; it does two main things:
  1. Uses a common memory context for arrays being constructed by
array_agg in any context (ungrouped, sorted agg, and HashAgg)  2. Reduces the initial array allocation to 8 elements
from64, but
 
preserves doubling behavior

I don't see either as a big problem, but perhaps there are some
downsides in some cases. I think a worst case would be a slowdown in
the sorted agg case where every group has 64 elements, so I'll try to
see if that's a real problem or not. If you saw a bigger problem,
please let me know; and if not, I'll proceed with the review.

There are also some other concerns I have about the API ugliness,
which I believe is the reason there's so much discussion about making
the comments better. The reason the API is ugly is for backwards
compatibility, so there's no perfect solution. Your opinion is welcome
here too, but I mainly need to see if your objection above has been
addressed.

Regards,   Jeff Davis



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Arne Scheffer
Дата:
Сообщение: Re: Add min and max execute statement time in pg_stat_statement
Следующее
От: Robert Haas
Дата:
Сообщение: Re: pgaudit - an auditing extension for PostgreSQL