Re: [HACKERS] vacuum process size

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: [HACKERS] vacuum process size
Дата
Msg-id 3691.935526084@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: [HACKERS] vacuum process size  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: [HACKERS] vacuum process size  (Tatsuo Ishii <t-ishii@sra.co.jp>)
Список pgsql-hackers
>> If there's no objection, I will commit included patches to the stable
>> tree (seems Tom has more aggressive idea, so I'll leave the current
>> tree as it is).

> No, please make the change in current as well.  I was thinking about
> tweaking aset.c to be smarter about releasing large chunks, but in any
> case having the doubling behavior at the request point will be a big
> improvement.

I have just committed changes into current (but not REL6_5) to make
aset.c smarter about giving back memory from large requests.  Basically,
for chunk sizes >= ALLOC_BIGCHUNK_LIMIT, pfree() does an actual free()
and repalloc() does an actual realloc().  There is no change in behavior
for smaller chunk sizes.  This should cap the amount of space that can
be wasted by aset.c while repalloc'ing a chunk larger and larger.

For lack of a better idea I set ALLOC_BIGCHUNK_LIMIT to 64K.  I don't
think it'd pay to make it very small, but I don't really know whether
this is a good choice or not.

It would still be a good idea to fix vacuum.c to double its repalloc
requests at each step, but Tatsuo was already working on that part
so I won't joggle his elbow...
        regards, tom lane


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

Предыдущее
От: "Hub.Org News Admin"
Дата:
Сообщение: ...
Следующее
От: Tom Lane
Дата:
Сообщение: Re: memory requirements question