Re: Use WALReadFromBuffers in more places
От | Jingtang Zhang |
---|---|
Тема | Re: Use WALReadFromBuffers in more places |
Дата | |
Msg-id | 92F510DF-321D-4385-B1D8-71781B50777B@gmail.com обсуждение исходный текст |
Ответ на | Re: Use WALReadFromBuffers in more places (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Список | pgsql-hackers |
Hi~ > Thanks for looking at this. Yes, the WAL writers can zero out flushed > buffers before WALReadFromBuffers gets to them. However, > WALReadFromBuffers was intentionally designed as an opportunistic > optimization - it's a "try this first, quickly" approach before > falling back to reading from WAL files. The no-locks design ensures it > never gets in the way of backends generating WAL, which is critical > for overall system performance. Yes, it is actually an interesting thing, beyond current topic. Since we are using buffered I/O, even though we cannot read from WAL buffer due to the opportunistic AdvanceXLInsertBuffer by WAL writer, later WALRead may still find the page inside OS page cache, with high probability, because the page has just been written out. So WALRead will be fast, too. But if we are moving forward to direct I/O some day in the future, the cost of WALReadFromBuffers and WALRead might be obvious. Maybe the opportunistic WAL buffer initialization could keep a small ratio of old pages inside WAL buffer so these pages can still be hit by WALReadFromBuffers. > I rebased and attached the v3 patch. The v3 patch LGTM. — Regards, Jingtang Alibaba Cloud
В списке pgsql-hackers по дате отправления: