reloption to prevent VACUUM from truncating empty pages at the end of relation

Поиск
Список
Период
Сортировка
От Fujii Masao
Тема reloption to prevent VACUUM from truncating empty pages at the end of relation
Дата
Msg-id CAHGQGwE5UqFqSq1=kV3QtTUtXphTdyHA-8rAj4A=Y+e4kyp3BQ@mail.gmail.com
обсуждение исходный текст
Ответы Re: reloption to prevent VACUUM from truncating empty pages at the end of relation  (Tom Lane <tgl@sss.pgh.pa.us>)
Re: reloption to prevent VACUUM from truncating empty pages at theend of relation  (Pavan Deolasee <pavan.deolasee@gmail.com>)
RE: reloption to prevent VACUUM from truncating empty pages at theend of relation  ("Tsunakawa, Takayuki" <tsunakawa.takay@jp.fujitsu.com>)
Список pgsql-hackers
Hi,

I'd like to propose to add $SUBJECT for performance improvement.

When VACUUM tries to truncate the trailing empty pages, it scans shared_buffers
to invalidate the pages-to-truncate during holding an AccessExclusive lock on
the relation. So if shared_buffers is huge, other transactions need to wait for
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.
Therefore, I'm thinking to propose $SUBJECT and enable it to avoid such spikes
for that relation.

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.

Thought?

Regards,

-- 
Fujii Masao


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

Предыдущее
От: John Naylor
Дата:
Сообщение: Re: WIP: a way forward on bootstrap data
Следующее
От: Tom Lane
Дата:
Сообщение: Re: WIP: a way forward on bootstrap data