Re: [HACKERS] Proposal : For Auto-Prewarm.

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [HACKERS] Proposal : For Auto-Prewarm.
Дата
Msg-id CAB7nPqQ15fv_NHVvmXT_W0AC3EnZSQVrEafyjW1KxhxUa5UKrA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Proposal : For Auto-Prewarm.  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] Proposal : For Auto-Prewarm.  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
On Tue, Jan 31, 2017 at 3:02 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> On Fri, Jan 27, 2017 at 5:34 PM, Jim Nasby <Jim.Nasby@bluetreble.com> wrote:
>> On 1/26/17 10:11 PM, Beena Emerson wrote:
>>> In that case, we could add the file location parameter.  By default it
>>> would store in the cluster directory else in the location provided. We
>>> can update this parameter in standby for it to access the file.
>>
>> I don't see file location being as useful in this case. What would be more
>> useful is being able to forcibly load blocks into shared buffers so that you
>> didn't need to restart.
>
> Of course, you can already do that with the existing pg_prewarm and
> pg_buffercache functionality.  Any time you want, you can use
> pg_buffercache to dump out a list of everything in shared_buffers, and
> pg_prewarm to suck that same stuff in on the same node or a separate
> node.  All this patch is trying to do is provide a convenient,
> automated way to make that work.
>
> (An argument could be made that this ought to be in core and the
> default behavior, because who really wants to start with an ice-cold
> cold buffer cache on a production system?  It's possible that
> repopulating shared_buffers in the background after a restart could
> cause enough I/O to interfere with foreground activity that
> regrettably ends up needing none of the prewarmed buffers, but I think
> prewarming a few GB of data should be quite fast under normal
> circumstances, and any well-intentioned system can go wrong under some
> set of obscure circumstances.  Still, the patch takes the conservative
> course of making this an opt-in behavior, and that's probably for the
> best.)

I partially agree with this paragraph, at least there are advantages
to do so for cases where the data fits in shared buffers. Even for
data sets fitting in RAM that can be an advantage as the buffers would
get evicted from Postgres' cache but not the OS. Now for cases where
there are many load patterns on a given database (I have some here),
that's hard to make this thing by default on.

This patch needs to be visibly reshaped anyway, so I am marking it as
returned with feedback.
-- 
Michael



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] macaddr 64 bit (EUI-64) datatype support
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] Review: GIN non-intrusive vacuum of posting tree