Re: WIP: WAL prefetch (another approach)
От | Tomas Vondra |
---|---|
Тема | Re: WIP: WAL prefetch (another approach) |
Дата | |
Msg-id | 20200806104701.j3xnkczd6qelfnhj@development обсуждение исходный текст |
Ответ на | Re: WIP: WAL prefetch (another approach) (Thomas Munro <thomas.munro@gmail.com>) |
Ответы |
Re: WIP: WAL prefetch (another approach)
|
Список | pgsql-hackers |
On Thu, Aug 06, 2020 at 02:58:44PM +1200, Thomas Munro wrote: >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. > OK, I'll see if I can still reproduce it. >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). Yeah, I noticed. I'll take a look and do some testing in the next CF. regards -- Tomas Vondra http://www.2ndQuadrant.com PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services
В списке pgsql-hackers по дате отправления: