Re: WIP: WAL prefetch (another approach)

Поиск
Список
Период
Сортировка
От Thomas Munro
Тема Re: WIP: WAL prefetch (another approach)
Дата
Msg-id CA+hUKGKfsWj+4qPfOkC4YtYtVO33yrCty1uWxBp3R1OSqWEcyA@mail.gmail.com
обсуждение исходный текст
Ответ на Re: WIP: WAL prefetch (another approach)  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: WIP: WAL prefetch (another approach)  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список pgsql-hackers
On Tue, Aug 4, 2020 at 3:47 AM Tomas Vondra
<tomas.vondra@2ndquadrant.com> wrote:
> On Thu, Jul 02, 2020 at 03:09:29PM +1200, Thomas Munro wrote:
> >FYI I am still trying to reproduce and understand the problem Tomas
> >reported; more soon.
>
> Any luck trying to reproduce thigs? Should I try again and collect some
> additional debug info?

No luck.  I'm working on it now, and also trying to reduce the
overheads so that we're not doing extra work when it doesn't help.

By the way, I also looked into recovery I/O stalls *other* than
relation buffer cache misses, and created
https://commitfest.postgresql.org/29/2669/ to fix what I found.  If
you avoid both kinds of stalls then crash recovery is finally CPU
bound (to go faster after that we'll need parallel replay).



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

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Add MAIN_RELATION_CLEANUP and SECONDARY_RELATION_CLEANUP options to VACUUM
Следующее
От: Amit Langote
Дата:
Сообщение: Re: FailedAssertion("pd_idx == pinfo->nparts", File: "execPartition.c", Line: 1689)