Re: [HACKERS] increasing the default WAL segment size
От | Michael Paquier |
---|---|
Тема | Re: [HACKERS] increasing the default WAL segment size |
Дата | |
Msg-id | CAB7nPqRjxUfeVNVrAzN-P6gi4Z8iTg-Tx8v0JhyaP-Wa8sy7-A@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: [HACKERS] increasing the default WAL segment size (Robert Haas <robertmhaas@gmail.com>) |
Список | pgsql-hackers |
On Thu, Jan 5, 2017 at 12:33 AM, Robert Haas <robertmhaas@gmail.com> wrote: > On Wed, Jan 4, 2017 at 9:47 AM, Simon Riggs <simon@2ndquadrant.com> wrote: >> On 4 January 2017 at 13:57, Robert Haas <robertmhaas@gmail.com> wrote: >>> On Wed, Jan 4, 2017 at 3:05 AM, Simon Riggs <simon@2ndquadrant.com> wrote: >>>> Strange response. Nothing has been assumed. I asked for tests and you >>>> provided measurements. >>> >>> Sure, of zero-filling a file with dd. But I also pointed out that in >>> a real PostgreSQL cluster, the change could actually *reduce* latency. >> >> I think we are talking at cross purposes. We agree that the main >> change is useful, but it causes another problem which I can't see how >> you can characterize as reduced latency, based upon your own >> measurements. > > Zero-filling files will take longer if the files are bigger. That > will increase latency. But we will also have fewer forced > end-of-segment syncs. That will reduce latency. Which effect is > bigger? It depends on if the environment is CPU-bounded or I/O bounded. If CPU is at its limit, zero-filling takes time. If that's the I/O, fsync() would take longer to complete. -- Michael
В списке pgsql-hackers по дате отправления: