From: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, Masahiko Sawada <sawada(dot)mshk(at)gmail(dot)com>, Anastasia Lubennikova <a(dot)lubennikova(at)postgrespro(dot)ru>, Anastasia Lubennikova <lubennikovaav(at)gmail(dot)com>, PostgreSQL-Dev <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: Vacuum: allow usage of more than 1GB of work mem |
Date: | 2017-04-11 19:04:44 |
Message-ID: | CAGTBQpZAVC0cMU7gOn3oXKmSZnd-49UhKs+QMBV7Wddm=u6ASA@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Apr 11, 2017 at 3:59 PM, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:
> On Tue, Apr 11, 2017 at 3:53 PM, Robert Haas <robertmhaas(at)gmail(dot)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).
From | Date | Subject | |
---|---|---|---|
Next Message | Heikki Linnakangas | 2017-04-11 19:07:12 | Re: scram and \password |
Previous Message | Claudio Freire | 2017-04-11 18:59:56 | Re: Vacuum: allow usage of more than 1GB of work mem |