On Fri, Jul 21, 2017 at 4:19 AM, Sokolov Yura <funny.fal...@postgrespro.ru> wrote: > You are one of leadership. I know it is not your job to test every tiny > change a school boy proposed. But here is a lot of people, who waits for > your word. Instead of cooling rush and closing discussions, you may just > say: "please, someone test it with that particular workload".
I had no intention of cooling rush and closing discussions. I was trying to help you understand what points you needed to address in order to have a chance of getting this committed. I feel like I came into this discussion to try to help you make some progress on this issue, and instead of appreciating that, you're making me the bad guy. > When there is no garbage, increasing autovacuum ring buffer changes almost > nothing. When there is garbage, current small ring buffer leads to a storm > of fsyncs. Frequent fsyncs slows down hdd a lot, and then hdd isn't capable > to satisfy queries and refill OS cache. Will you admit it? I haven't tested it, but it sounds believable. >> I've also run into many customers whose problem that vacuum ran too >> slowly, and generally raising vacuum_cost_limit fixes that problem just >> fine. > > Probably with increased ring buffer there is no need in raising > vacuum_cost_limit. Will you admit it? No, I definitely won't admit that. With default settings autovacuum won't write more than ~2.3MB/s if I remember the math correctly, so if you've got a 1TB table you're probably going to need a bigger value. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers