From: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr> |
---|---|
To: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
Cc: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: checkpointer continuous flushing |
Date: | 2015-06-24 04:26:04 |
Message-ID: | alpine.DEB.2.10.1506240621130.3535@sto |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
>> I do not see how to do both, as these two orders seem more or less
>> unrelated? The traditionnal assumption is that the I/O are very slow
>> and they are to be optimized first, so going for buffer ordering to be
>> nice to the disk looks like the priority.
>
> The point is that it's already expensive for backends to advance the clock;
> if they then have to wait on IO as well it gets REALLY expensive. So we want
> to avoid that.
I do not know what this clock stuff does. Note that the checkpoint buffer
scan is done once at the beginning of the checkpoint and its time is
relatively small compared to everything else in the checkpoint.
If this scan is an issue, it can be done in reverse order, or in some
other order, but I think it is better to do it in order for better cache
behavior, although the effect should be marginal.
--
Fabien.
From | Date | Subject | |
---|---|---|---|
Next Message | Fabien COELHO | 2015-06-24 06:29:04 | Re: checkpointer continuous flushing |
Previous Message | Fabien COELHO | 2015-06-24 04:20:31 | Re: checkpointer continuous flushing |