RE: reloption to prevent VACUUM from truncating empty pages at theend of relation

Поиск
Список
Период
Сортировка
От Tsunakawa, Takayuki
Тема RE: reloption to prevent VACUUM from truncating empty pages at theend of relation
Дата
Msg-id 0A3221C70F24FB45833433255569204D1F944A89@G01JPEXMBYT05
обсуждение исходный текст
Ответ на reloption to prevent VACUUM from truncating empty pages at the end of relation  (Fujii Masao <masao.fujii@gmail.com>)
Список pgsql-hackers
From: Fujii Masao [mailto:masao.fujii@gmail.com]
> a very long time before accessing to the relation. Which would cause the
> response-time spikes, for example, I observed such spikes several times
> on
> the server with shared_buffers = 300GB while running the benchmark.

FYI, a long transaction took about 900 ms, while the average transaction response time was 150 ms or so.  (I'm working
withFujii-san in this performance benchmark.)
 


> Therefore, I'm thinking to propose $SUBJECT and enable it to avoid such
> spikes
> for that relation.

How about an integer variable to replace the following?

#define REL_TRUNCATE_FRACTION    16


> Also, first of all, if other transactions need to extend the relation
> (i.e., need new pages) as soon as VACUUM truncates the empty pages at the
> end,
> that truncation would not be so helpful for performance. In this case,
> the truncation and extension of the relation are unnecessarily repeated,
> which would decrease the performance. So, to alleviate this situation,
> $SUBJECT is useful, I think.

I wonder if fillfactor=50 would alleviate this situation.

Regards
Takayuki Tsunakawa


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

Предыдущее
От: Catalin Iacob
Дата:
Сообщение: Is a modern build system acceptable for older platforms
Следующее
От: Amit Langote
Дата:
Сообщение: Re: [HACKERS] Runtime Partition Pruning