Re: Increase Vacuum ring buffer.

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Claudio Freire <klaussfreire(at)gmail(dot)com>
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>
Subject: Re: Increase Vacuum ring buffer.
Date: 2017-07-20 15:51:55
Message-ID: CA+Tgmob1TN80rCUUSBc3Sm_gYTcCu1HEWkVn4UieMx65zmZb0Q@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Thu, Jul 20, 2017 at 11:09 AM, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:
>> 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. I'm not certain what the right
>> decision is here, but I think that a careful analysis of possible
>> downsides is needed.
>
> IIRC, originally, the default shared_buffers settings was tiny.

It is true that we increased the default shared_buffers value from
32MB to 128MB in f358428280953643313ee7756e0a8b8ccfde7660, but it's
also true ring buffers are capped at 1/8th of shared_buffers
regardless of anything else, so I don't think that's the explanation
here. Even if that weren't the case, how would a 4x increase in the
default size of shared_buffers (which is probably the most-commonly
changed GUC of any that PostgreSQL has) justify a 64x increase in the
size of the ring buffer?

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message David G. Johnston 2017-07-20 15:57:37 Re: pg_upgrade failed if view contain natural left join condition
Previous Message Robert Haas 2017-07-20 15:48:00 Re: GSoC 2017: weekly progress reports (week 7)