Re: array_agg() on a set larger than some arbitrary(?) limit causes runaway memory usage and eventually memory exhaustion

Поиск
Список
Период
Сортировка
От Frank van Vugt
Тема Re: array_agg() on a set larger than some arbitrary(?) limit causes runaway memory usage and eventually memory exhaustion
Дата
Msg-id 3014614.ujIC87ofob@techfox.foxi
обсуждение исходный текст
Ответ на Re: array_agg() on a set larger than some arbitrary(?) limit causes runaway memory usage and eventually memory exhaustion  ("Tomas Vondra" <tv@fuzzy.cz>)
Ответы Re: array_agg() on a set larger than some arbitrary(?) limit causes runaway memory usage and eventually memory exhaustion  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-bugs
Hi,

Op zondag 20 oktober 2013 12:57:43 schreef Tomas Vondra:
> Attached is a quick patch removing the local memory context and using
> aggcontext instead. I've also tuned down the preallocation. It's against
> 9.2 stable, so it should apply fine against your 9.2.4. But be careful,
> it's not really tested.

I applied the patch and ran my queries again with the following results:



> with g as (select * from f limit 1e5)
>         select array_agg(id), min(value)

used to be:
    Time: 361,242 ms
now:
    Time: 363,767 ms



> with g as (select * from f limit 1e6)
>         select array_agg(id), min(value)

used to be:
    Time: 3310,347 ms
now:
    Time: 2134,688 ms



> with g as (select * from f limit 1e7)
>         select array_agg(id), min(value)

used to be:
    Time: <none, fails>
now:
    Time: 23234,045 ms

The last query now uses up ~3.5GB of memory.





and as for the comcat() / string_agg() comparison:

> with g as (select * from f limit 1e7)
>         select comcat(id::text), min(value)

used to be / still is:
    Time: ~18.5 seconds
    Mem: ~6,5 GB


> with g as (select * from f limit 1e7)
>         select string_agg(id::text, ', '), min(value)

used to be:
    Time: ~28.5 seconds
    Mem: ~16 GB
now:
    Time: ~28.5 seconds
    Mem: ~12 GB



So, the patch seems to have the desired effect ;)

It looks like this didn't go into git yet. Will it be in v9.2.6/v9.3.1? Since
it's still a 'rough' patch, I reversed it on our development server for now.





--

Best,




Frank.

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

Предыдущее
От: Jeevan Chalke
Дата:
Сообщение: Re: surprising to_timestamp behavior
Следующее
От: przemek@hadapt.com
Дата:
Сообщение: BUG #8572: Combination of SET TIME ZONEs and CAST gives wrong results