Horton

Re: Vacuum: allow usage of more than 1GB of work mem

Simon Riggs <simon@2ndquadrant.com>

View thread View on postgr.es
From: Simon Riggs <simon@2ndquadrant.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Simon Riggs <simon@2ndquadrant.com>, Tom Lane <tgl@sss.pgh.pa.us>, Claudio Freire <klaussfreire@gmail.com>, Jim Nasby <Jim.Nasby@bluetreble.com>, PostgreSQL-Dev <pgsql-hackers@postgresql.org>
Date: 2016-09-06T18:51:14Z
Lists: pgsql-hackers 
On 6 September 2016 at 19:23, Robert Haas <robertmhaas@gmail.com> wrote:
> On Tue, Sep 6, 2016 at 2:16 PM, Simon Riggs <simon@2ndquadrant.com> wrote:
>> What occurs to me is that we can exactly predict how many tuples we
>> are going to get when we autovacuum, since we measure that and we know
>> what the number is when we trigger it.
>>
>> So there doesn't need to be any guessing going on at all, nor do we
>> need it to be flexible.
>
> No, that's not really true.  A lot can change between the time it's
> triggered and the time it happens, or even while it's happening.
> Somebody can run a gigantic bulk delete just after we start the
> VACUUM.

Which wouldn't be removed by the VACUUM, so can be ignored.

-- 
Simon Riggs                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

Commits

  1. Prefetch blocks during lazy vacuum's truncation scan

  2. Explain unaccounted for space in pgstattuple.