reloption to prevent VACUUM from truncating empty pages at the end of relation - Mailing list pgsql-hackers

From Fujii Masao
Subject reloption to prevent VACUUM from truncating empty pages at the end of relation
Date
Msg-id CAHGQGwE5UqFqSq1=kV3QtTUtXphTdyHA-8rAj4A=Y+e4kyp3BQ@mail.gmail.com
Whole thread Raw
Responses 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>)
List 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 by date:

Previous
From: John Naylor
Date:
Subject: Re: WIP: a way forward on bootstrap data
Next
From: Tom Lane
Date:
Subject: Re: WIP: a way forward on bootstrap data