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:

Reply via email to