From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Michail Nikolaev <michail(dot)nikolaev(at)gmail(dot)com> |
Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: thoughts on "prevent wraparound" vacuum |
Date: | 2019-07-20 20:02:22 |
Message-ID: | 20190720200222.a2pjrxrthk5qfqyr@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
Hi,
On 2019-07-20 15:35:57 +0300, Michail Nikolaev wrote:
> Currently I am working a lot with cluster consist a few of big tables.
> About 2-3 TB. These tables are heavily updated, some rows are removed, new
> rows are inserted... Kind of typical OLTP workload.
>
> Physical table size keeps mostly stable while regular VACUUM is working. It
> is fast enough to clean some place from removed rows.
>
> But time to time "to prevent wraparound" comes. And it works like 8-9 days.
> During that time relation size starting to expand quickly. Freezing all
> blocks in such table takes a lot of time and bloat is generated much more
> quickly.
Several questions:
- Which version of postgres is this? Newer versions avoid scanning
unchanged parts of the heap even for freezing (9.6+, with additional
smaller improvements in 11).
- have you increased the vacuum cost limits? Before PG 12 they're so low
they're entirely unsuitable for larger databases, and even in 12 you
should likely increase them for a multi-TB database
Unfortunately even if those are fixed the indexes are still likely going
to be scanned in their entirety - but most of the time not modified
much, so that's not as bad.
Greetings,
Andres Freund
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2019-07-20 20:03:10 | Re: [RFC] Removing "magic" oids |
Previous Message | Noah Misch | 2019-07-20 19:58:55 | Re: [RFC] Removing "magic" oids |