On Thu, Jul 20, 2017 at 7:59 AM, Robert Haas <robertmh...@gmail.com> wrote:
> > > > 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. Cheers, Jeff
