Re: Vacuum: allow usage of more than 1GB of work mem
Claudio Freire <klaussfreire@gmail.com>
From: Claudio Freire <klaussfreire@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Andres Freund <andres@anarazel.de>,
Masahiko Sawada <sawada.mshk@gmail.com>, Anastasia Lubennikova <a.lubennikova@postgrespro.ru>, Anastasia Lubennikova <lubennikovaav@gmail.com>,
PostgreSQL-Dev <pgsql-hackers@postgresql.org>
Date: 2017-04-11T19:04:44Z
Lists: pgsql-hackers
On Tue, Apr 11, 2017 at 3:59 PM, Claudio Freire <klaussfreire@gmail.com> wrote: > On Tue, Apr 11, 2017 at 3:53 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> 1TB / 8kB per page * 60 tuples/page * 20% * 6 bytes/tuple = 9216MB of >> maintenance_work_mem >> >> So we'll allocate 128MB+256MB+512MB+1GB+2GB+4GB which won't be quite >> enough so we'll allocate another 8GB, for a total of 16256MB, but more >> than three-quarters of that last allocation ends up being wasted. >> I've been told on this list before that doubling is the one true way >> of increasing the size of an allocated chunk of memory, but I'm still >> a bit unconvinced. > > There you're wrong. The allocation is capped to 1GB, so wastage has an > upper bound of 1GB. And total m_w_m for vacuum is still capped to 12GB (as big you can get with 32-bit integer indices). So you can get at most 15 segments (a binary search is thus not worth it), and overallocate by at most 1GB (the maximum segment size). At least that's my rationale. Removing the 12GB limit requires a bit of care (there are some 32-bit counters still around I believe).
Commits
-
Prefetch blocks during lazy vacuum's truncation scan
- 7e26e02eec90 10.0 landed
-
Explain unaccounted for space in pgstattuple.
- 71f996d22125 10.0 cited