Re: [HACKERS] Increase Vacuum ring buffer.
| От | Jeff Janes |
|---|---|
| Тема | Re: [HACKERS] Increase Vacuum ring buffer. |
| Дата | |
| Msg-id | CAMkU=1ziPhBJD-XJNGjLBcowddN3-ior3dz80dpVdqqgL342kQ@mail.gmail.com обсуждение исходный текст |
| Ответ на | Re: [HACKERS] Increase Vacuum ring buffer. (Robert Haas <robertmhaas@gmail.com>) |
| Список | pgsql-hackers |
On Thu, Jul 20, 2017 at 7:59 AM, Robert Haas <robertmhaas@gmail.com> wrote:
I think the question for this patch is "so, why didn't we do it this>
> 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.
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 по дате отправления: