Re: Fsync request queue
От | Robert Haas |
---|---|
Тема | Re: Fsync request queue |
Дата | |
Msg-id | CA+Tgmoa9ZLSuOnuYbAAnGJnfUyRWrY9uLUpCsE31hCEC3LonwA@mail.gmail.com обсуждение исходный текст |
Ответ на | Re: Fsync request queue (Andres Freund <andres@anarazel.de>) |
Ответы |
Re: Fsync request queue
|
Список | pgsql-hackers |
On Tue, May 1, 2018 at 1:41 PM, Andres Freund <andres@anarazel.de> wrote: > I unfortunately don't have access to the relevant reports anymore, so > it's only by memory. What I do remember is that a few I saw > pg_stat_bgwriter.buffers_backend_fsync values that we a pretty sizable > fraction of the buffers written by backends. I don't think I ever > figured out how problematic that was from a peformance perspective, and > how large a fraction of the overall number of fsyncs those were. > > One was a workload with citus (lots of tables per node), and one was > inheritance based partitioning. There were a few others too, where I > don't recall anything about the workload. Hmm. Partitioning probably does make it easier to overrun the queue, but even so it seems hard -- the queue has one entry per shared buffer, which is a lot. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: