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

Поиск
Список
Период
Сортировка
От Michael Paquier
Тема Re: [HACKERS] Proposal : For Auto-Prewarm.
Дата
Msg-id CAB7nPqQ4dZ3EFjDv_RYPD5vijKX6v2C2AEA-69wfpznfTAWbzw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: [HACKERS] Proposal : For Auto-Prewarm.  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: [HACKERS] Proposal : For Auto-Prewarm.  (Mithun Cy <mithun.cy@enterprisedb.com>)
Список pgsql-hackers
On Wed, Feb 1, 2017 at 1:17 AM, Robert Haas <robertmhaas@gmail.com> wrote:
> Well, the question even for that case is whether it really costs
> anything.  My bet is that it is nearly free when it doesn't help, but
> that could be wrong.  My experience running pgbench tests is that
> prewarming all of pgbench_accounts on a scale factor that fits in
> shared_buffers using "dd" took just a few seconds, but when accessing
> the blocks in random order the cache took many minutes to heat up.

And benchmarks like dbt-1 have a pre-warming period added in the test
itself where the user can specify in a number of seconds to linearly
increase the load from 0% to 100%, just for filling in the OS and PG's
cache... This feature would be helpful.

> Now, I assume that this patch sorts the I/O (although I haven't
> checked that) and therefore I expect that the prewarm completes really
> fast.  If that's not the case, then that's bad.  But if it is the
> case, then it's not really hurting you even if the workload changes
> completely.

Having that working fast would be really nice.
-- 
Michael



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] logical decoding of two-phase transactions
Следующее
От: Michael Paquier
Дата:
Сообщение: Re: [HACKERS] WAL consistency check facility