Re: Berserk Autovacuum (let's save next Mandrill) - Mailing list pgsql-hackers

From Darafei "Komяpa" Praliaskouski
Subject Re: Berserk Autovacuum (let's save next Mandrill)
Date
Msg-id CAC8Q8tLnRiMg9++F+mhNDX_M8VcjQnvfdJ7Hvo2VsmWL9-2Esw@mail.gmail.com
Whole thread Raw
In response to Re: Berserk Autovacuum (let's save next Mandrill)  (David Rowley <david.rowley@2ndquadrant.com>)
Responses Re: Berserk Autovacuum (let's save next Mandrill)
List pgsql-hackers


On Thu, Mar 28, 2019 at 2:36 AM David Rowley <david.rowley@2ndquadrant.com> wrote:
On Thu, 28 Mar 2019 at 11:01, Alvaro Herrera <alvherre@2ndquadrant.com> wrote:
>
> On 2019-Mar-28, Darafei "Komяpa" Praliaskouski wrote:
> > "Nearing wraparound" is too late already. In Amazon, reading table from gp2
> > after you exhausted your IOPS burst budget is like reading a floppy drive,
> > you have to freeze a lot earlier than you hit several terabytes of unfrozen
> > data, or you're dead like Mandrill's Search and Url tables from the link I
> > shared.
>
> OK, then start freezing tuples in the cheap mode (skip index updates)
> earlier than that.  I suppose a good question is when to start.

I thought recently that it would be good to have some sort of
pro-active auto-vacuum mode that made use of idle workers. 

Problem with "idle" is that it never happens on system that are going to wraparound on their lifetime. This has to be a part of normal database functioning.

Why not select a table that has inserts, updates and deletes for autovacuum just like we do for autoanalyze, not only deletes and updates like we do now?


--
Darafei Praliaskouski

pgsql-hackers by date:

Previous
From: "Nagaura, Ryohei"
Date:
Subject: RE: Timeout parameters
Next
From: Peter Eisentraut
Date:
Subject: Re: idle-in-transaction timeout error does not give a hint