Re: finding changed blocks using WAL scanning
От | Andres Freund |
---|---|
Тема | Re: finding changed blocks using WAL scanning |
Дата | |
Msg-id | 20190423163454.7mbljqagrsbqhmlc@alap3.anarazel.de обсуждение исходный текст |
Ответ на | Re: finding changed blocks using WAL scanning (Tomas Vondra <tomas.vondra@2ndquadrant.com>) |
Ответы |
Re: finding changed blocks using WAL scanning
|
Список | pgsql-hackers |
Hi, On 2019-04-23 18:07:40 +0200, Tomas Vondra wrote: > Well, the thing is that for prefetching to be possible you actually have > to be a bit behind. Otherwise you can't really look forward which blocks > will be needed, right? > > IMHO the main use case for prefetching is when there's a spike of activity > on the primary, making the standby to fall behind, and then hours takes > hours to catch up. I don't think the cases with just a couple of MBs of > lag are the issue prefetching is meant to improve (if it does, great). I'd be surprised if a good implementation didn't. Even just some smarter IO scheduling in the startup process could help a good bit. E.g. no need to sequentially read the first and then the second block for an update record, if you can issue both at the same time - just about every storage system these days can do a number of IO requests in parallel, and it nearly halves latency effects. And reading a few records (as in a few hundred bytes commonly) ahead, allows to do much more than that. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: