| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Peter Geoghegan <pg(at)bowt(dot)ie>, Heikki Linnakangas <hlinnaka(at)iki(dot)fi>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Fsync request queue |
| Date: | 2018-05-01 17:41:43 |
| Message-ID: | 20180501174143.gpe7bksu43skw5y4@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2018-05-01 13:21:21 -0400, Robert Haas wrote:
> On Mon, Apr 30, 2018 at 7:08 PM, Andres Freund <andres(at)anarazel(dot)de> wrote:
> >> True, but has anyone ever actually observed a non-zero
> >> pg_stat_bgwriter.buffers_backend_fsync in the wild after the
> >> compaction queue stuff was added/backpatched?
> >
> > Yes.
>
> Care to elaborate?
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.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Robert Haas | 2018-05-01 17:43:14 | Re: Fsync request queue |
| Previous Message | Robert Haas | 2018-05-01 17:41:32 | Re: Oddity in tuple routing for foreign partitions |