| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
| Cc: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: checkpointer continuous flushing |
| Date: | 2016-01-07 20:17:32 |
| Message-ID: | 20160107201731.GN7650@awork2.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2016-01-07 21:08:10 +0100, Fabien COELHO wrote:
> Hmmm. What I understood is that the workloads that have some performance
> regressions (regressions that I have *not* seen in the many tests I ran) are
> not due to checkpointer IOs, but rather in settings where most of the writes
> is done by backends or bgwriter.
As far as I can see you've not run many tests where the hot/warm data
set is larger than memory (the full machine's memory, not
shared_buffers). That quite drastically alters the performance
characteristics here, because you suddenly have lots of synchronous read
IO thrown into the mix.
Whether it's bgwriter or not I've not fully been able to establish, but
it's a working theory.
> I do not see the point of rewriting the checkpointer for them, although
> obviously I agree that something has to be done also for the other
> processes.
Rewriting the checkpointer and fixing the flush interface in a more
generic way aren't the same thing at all.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Jim Nasby | 2016-01-07 20:30:06 | Interesting read on SCM upending software and hardware architecture |
| Previous Message | Alvaro Herrera | 2016-01-07 20:16:48 | Re: Re: [COMMITTERS] pgsql: Windows: Make pg_ctl reliably detect service status |