Re: New statistics for tuning WAL buffer size
От | Masahiro Ikeda |
---|---|
Тема | Re: New statistics for tuning WAL buffer size |
Дата | |
Msg-id | b10a26b5de90a9ae8c4743993fcd7bc2@oss.nttdata.com обсуждение исходный текст |
Ответ на | Re: New statistics for tuning WAL buffer size (Masahiro Ikeda <ikedamsh@oss.nttdata.com>) |
Ответы |
Re: New statistics for tuning WAL buffer size
|
Список | pgsql-hackers |
On 2020-08-24 20:45, Masahiro Ikeda wrote: > Hi, thanks for useful comments. > >>> I agree to expose the number of WAL write caused by full of WAL >>> buffers. >>> It's helpful when tuning wal_buffers size. Haribabu separated that >>> number >>> into two fields in his patch; one is the number of WAL write by >>> backend, >>> and another is by background processes and workers. But I'm not sure >>> how useful such separation is. I'm ok with just one field for that >>> number. >> I agree with you. I don't think we need to separate the numbers for >> foreground processes and background ones. WAL buffer is a single >> resource. So "Writes due to full WAL buffer are happening. We may be >> able to boost performance by increasing wal_buffers" would be enough. > > I made a patch to expose the number of WAL write caused by full of WAL > buffers. > I'm going to submit this patch to commitfests. > > As Fujii-san and Tsunakawa-san said, it expose the total number > since I agreed that we don't need to separate the numbers for > foreground processes and background ones. > > By the way, do we need to add another metrics related to WAL? > For example, is the total number of WAL writes to the buffers useful > to calculate the dirty WAL write ratio? > > Is it enough as a first step? I forgot to rebase the current master. I've attached the rebased patch. Regards, -- Masahiro Ikeda NTT DATA CORPORATION
Вложения
В списке pgsql-hackers по дате отправления: