Re: Improve WALRead() to suck data directly from WAL buffers when possible
От | Nathan Bossart |
---|---|
Тема | Re: Improve WALRead() to suck data directly from WAL buffers when possible |
Дата | |
Msg-id | 20230301041523.GA1453450@nathanxps13 обсуждение исходный текст |
Ответ на | Re: Improve WALRead() to suck data directly from WAL buffers when possible (Bharath Rupireddy <bharath.rupireddyforpostgres@gmail.com>) |
Ответы |
Re: Improve WALRead() to suck data directly from WAL buffers when possible
|
Список | pgsql-hackers |
On Tue, Feb 28, 2023 at 10:38:31AM +0530, Bharath Rupireddy wrote: > On Tue, Feb 28, 2023 at 6:14 AM Nathan Bossart <nathandbossart@gmail.com> wrote: >> Why do we only read a page at a time in XLogReadFromBuffersGuts()? What is >> preventing us from copying all the data we need in one go? > > Note that most of the WALRead() callers request a single page of > XLOG_BLCKSZ bytes even if the server has less or more available WAL > pages. It's the streaming replication wal sender that can request less > than XLOG_BLCKSZ bytes and upto MAX_SEND_SIZE (16 * XLOG_BLCKSZ). And, > if we read, say, MAX_SEND_SIZE at once while holding > WALBufMappingLock, that might impact concurrent inserters (at least, I > can say it in theory) - one of the main intentions of this patch is > not to impact inserters much. Perhaps we should test both approaches to see if there is a noticeable difference. It might not be great for concurrent inserts to repeatedly take the lock, either. If there's no real difference, we might be able to simplify the code a bit. -- Nathan Bossart Amazon Web Services: https://aws.amazon.com
В списке pgsql-hackers по дате отправления: