| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Stephen Frost <sfrost(at)snowman(dot)net> |
| Cc: | Sokolov Yura <funny(dot)falcon(at)postgrespro(dot)ru>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers-owner(at)postgresql(dot)org |
| Subject: | Re: Increase Vacuum ring buffer. |
| Date: | 2017-07-20 19:34:59 |
| Message-ID: | CA+TgmoZvhX8mJCFHm+uLdYmpoz4sA6As1Y=g33XbKXoEwJG6=w@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Thu, Jul 20, 2017 at 3:04 PM, Stephen Frost <sfrost(at)snowman(dot)net> wrote:
> I agree that it's a common problem for VACUUM to go too fast, or for
> VACUUM to go too slow, but that's really what the vacuum_cost_limit
> mechanism is for.
I think that's a valid point. There are also other concerns here -
e.g. whether instead of adopting the patch as proposed we ought to (a)
use some smaller size, or (b) keep the size as-is but reduce the
maximum fraction of shared_buffers that can be consumed, or (c) divide
the ring buffer size through by autovacuum_max_workers. Personally,
of those approaches, I favor (b). I think a 16MB ring buffer is
probably just fine if you've got 8GB of shared_buffers but I'm
skeptical about it when you've got 128MB of shared_buffers.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Stephen Frost | 2017-07-20 19:37:44 | Re: Increase Vacuum ring buffer. |
| Previous Message | Robert Haas | 2017-07-20 19:31:20 | Re: Error while copying a large file in pg_rewind |