Re: [HACKERS] Increase Vacuum ring buffer. - Mailing list pgsql-hackers

From Jeff Janes
Subject Re: [HACKERS] Increase Vacuum ring buffer.
Date
Msg-id CAMkU=1ziPhBJD-XJNGjLBcowddN3-ior3dz80dpVdqqgL342kQ@mail.gmail.com
Whole thread Raw
In response to Re: [HACKERS] Increase Vacuum ring buffer.  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On Thu, Jul 20, 2017 at 7:59 AM, Robert Haas <robertmhaas@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

pgsql-hackers by date:

Previous
From: Alik Khilazhev
Date:
Subject: Re: [HACKERS] [WIP] Zipfian distribution in pgbench
Next
From: Fabien COELHO
Date:
Subject: Re: [HACKERS] [WIP] Zipfian distribution in pgbench