Re: PATCH: decreasing memory needlessly consumed by array_agg - Mailing list pgsql-hackers

From Jeff Davis
Subject Re: PATCH: decreasing memory needlessly consumed by array_agg
Date
Msg-id CAMp0ubccbTmQwuyb9dUeQLr+fTDKtOJk0ceCaJg7SBMYJbVTkg@mail.gmail.com
Whole thread Raw
In response to Re: PATCH: decreasing memory needlessly consumed by array_agg  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: PATCH: decreasing memory needlessly consumed by array_agg
Re: PATCH: decreasing memory needlessly consumed by array_agg
List 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 by date:

Previous
From: Arne Scheffer
Date:
Subject: Re: Add min and max execute statement time in pg_stat_statement
Next
From: Robert Haas
Date:
Subject: Re: pgaudit - an auditing extension for PostgreSQL