On 2017-07-20 22:51, Tom Lane wrote:
> 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
Attached version is with min(shared_buffers/8/autovacuum_workers, 16MB).
With regards
--
Sokolov Yura aka funny_falcon
Postgres Professional: https://postgrespro.ru
The Russian Postgres Company
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers