Re: Improve WALRead() to suck data directly from WAL buffers when possible
От | Andres Freund |
---|---|
Тема | Re: Improve WALRead() to suck data directly from WAL buffers when possible |
Дата | |
Msg-id | 20230114203403.4zpg72fw2qb34awf@awork3.anarazel.de обсуждение исходный текст |
Ответ на | Re: Improve WALRead() to suck data directly from WAL buffers when possible (Jeff Davis <pgsql@j-davis.com>) |
Ответы |
Re: Improve WALRead() to suck data directly from WAL buffers when possible
Re: Improve WALRead() to suck data directly from WAL buffers when possible Re: Improve WALRead() to suck data directly from WAL buffers when possible |
Список | pgsql-hackers |
Hi, On 2023-01-14 00:48:52 -0800, Jeff Davis wrote: > On Mon, 2022-12-26 at 14:20 +0530, Bharath Rupireddy wrote: > > Please review the attached v2 patch further. > > I'm still unclear on the performance goals of this patch. I see that it > will reduce syscalls, which sounds good, but to what end? > > Does it allow a greater number of walsenders? Lower replication > latency? Less IO bandwidth? All of the above? One benefit would be that it'd make it more realistic to use direct IO for WAL - for which I have seen significant performance benefits. But when we afterwards have to re-read it from disk to replicate, it's less clearly a win. Greetings, Andres Freund
В списке pgsql-hackers по дате отправления: