Re: Berserk Autovacuum (let's save next Mandrill)
| От | Darafei "Komяpa" Praliaskouski |
|---|---|
| Тема | Re: Berserk Autovacuum (let's save next Mandrill) |
| Дата | |
| Msg-id | CAC8Q8tLnRiMg9++F+mhNDX_M8VcjQnvfdJ7Hvo2VsmWL9-2Esw@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: Berserk Autovacuum (let's save next Mandrill) (David Rowley <david.rowley@2ndquadrant.com>) |
| Ответы |
Re: Berserk Autovacuum (let's save next Mandrill)
|
| Список | 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
Support me: http://patreon.com/komzpa
В списке pgsql-hackers по дате отправления: