> > Initially I wanted to make BAS_BULKWRITE and BAS_VACUUM ring sizes > configurable, but after testing I don't see much gain from increasing > ring buffer above 16MB. So I propose just 1 line change.
I think the question for this patch is "so, why didn't we do it this way originally?".
It's no secret that making the ring buffer larger will improve performance -- in fact, not having a ring buffer at all would improve performance even more. But it would also increase the likelihood that the background work of vacuum would impact the performance of foreground operations, which is already a pretty serious problem that we probably don't want to make worse.
But having a very fast sequence of fdatasync calls is not terribly friendly to the performance of the foreground operations, either.
I think the reason we didn't do it this way originally is tied the same reason that autovacuum_vacuum_cost_delay = 20ms by default. If we want it to be heavily throttled, there isn't much point in using a larger ring buffer. It is just wasted space. Maybe we could have it start out at BAS_VACUUM's default size, then grow by one buffer every time it had to issue a WAL sync, until it reached BAS_BULKWRITE's size where it would max out.