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 CAC8Q8tKYwszESatKrj+3JYzR_iM6o0obtUFuS_KTNLahigpf_w@mail.gmail.com
Whole thread Raw
In response to Re: Berserk Autovacuum (let's save next Mandrill)  (Vik Fearing <vik.fearing@2ndquadrant.com>)
List pgsql-hackers

> Idea: look not on dead tuples, but on changes, just like ANALYZE does.
> It's my first patch on Postgres, it's probably all wrong but I hope it
> helps you get the idea.

This was suggested and rejected years ago:
https://www.postgresql.org/message-id/b970f20f-f096-2d3a-6c6d-ee887bd30cfb@2ndquadrant.fr

Thank you for sharing the link. I've read through the thread and see you posted two patches, first being similar but different from mine, and second being about a different matter.

I don't see "rejected" there, just a common distraction of "you should also consider this" and time-out leading to "returned with feedback" at the end.

Thing is, we have dead large productions and post-mortems now as your patch wasn't pushed back in 2016, so situation is different. Let's push at least first of two patches of yours, or mine.

Which one is better and why?

I believe mine, as it just follows a pattern already established and proven in autoanalyze. If vacuum comes and unable to harvest some dead tuples, it will come over again in your case, and just sleep until it gets new dead tuples in mine, which looks better to me - there's no dead loop in case some dead tuples are stuck forever.
If someone thinks yours is better we may also consider it for autoanalyze?


--
Darafei Praliaskouski

pgsql-hackers by date:

Previous
From: Darafei "Komяpa" Praliaskouski
Date:
Subject: Re: Berserk Autovacuum (let's save next Mandrill)
Next
From: David Rowley
Date:
Subject: Re: COPY FROM WHEN condition