Re: [HACKERS] Increase Vacuum ring buffer.
От | Tom Lane |
---|---|
Тема | Re: [HACKERS] Increase Vacuum ring buffer. |
Дата | |
Msg-id | 12790.1500580319@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: [HACKERS] Increase Vacuum ring buffer. (Robert Haas <robertmhaas@gmail.com>) |
Ответы |
Re: [HACKERS] Increase Vacuum ring buffer.
Re: [HACKERS] Increase Vacuum ring buffer. |
Список | pgsql-hackers |
Robert Haas <robertmhaas@gmail.com> writes: > 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. WFM. I agree with *not* dividing the basic ring buffer size by autovacuum_max_workers. If you have allocated more AV workers, I think you expect AV to go faster, not for the workers to start fighting among themselves. It might, however, be reasonable for the fraction-of-shared-buffers limitation to have something to do with autovacuum_max_workers, so that you can't squeeze yourself out of shared_buffers if you set that number really high. IOW, I think the upthread suggestion of min(shared_buffers/8/autovacuum_workers, 16MB) is basically the right idea, though we could debate the exact constants. regards, tom lane
В списке pgsql-hackers по дате отправления: