From: | Andres Freund <andres(at)anarazel(dot)de> |
---|---|
To: | Tomas Vondra <tomas(dot)vondra(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: checkpointer continuous flushing - V16 |
Date: | 2016-03-07 17:50:33 |
Message-ID: | 20160307175033.dzlc5zvefqvdin4y@alap3.anarazel.de |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 2016-03-07 09:41:51 -0800, Andres Freund wrote:
> > Due to the difference in amount of RAM, each machine used different scales -
> > the goal is to have small, ~50% RAM, >200% RAM sizes:
> >
> > 1) Xeon: 100, 400, 6000
> > 2) i5: 50, 200, 3000
> >
> > The commits actually tested are
> >
> > cfafd8be (right before the first patch)
> > 7975c5e0 Allow the WAL writer to flush WAL at a reduced rate.
> > db76b1ef Allow SetHintBits() to succeed if the buffer's LSN ...
>
> Huh, now I'm a bit confused. These are the commits you tested? Those
> aren't the ones doing sorting and flushing?
To clarify: The reason we'd not expect to see much difference here is
that the above commits really only have any affect above noise if you
use synchronous_commit=off. Without async commit it's just one
additional gettimeofday() call and a few additional branches in the wal
writer every wal_writer_delay.
Andres
From | Date | Subject | |
---|---|---|---|
Next Message | Andres Freund | 2016-03-07 18:05:58 | Re: checkpointer continuous flushing - V18 |
Previous Message | Masahiko Sawada | 2016-03-07 17:41:57 | Re: Freeze avoidance of very large table. |