From: | Jim Nasby <Jim(dot)Nasby(at)BlueTreble(dot)com> |
---|---|
To: | Fabien COELHO <coelho(at)cri(dot)ensmp(dot)fr>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
Cc: | Andres Freund <andres(at)anarazel(dot)de>, PostgreSQL Developers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: checkpointer continuous flushing |
Date: | 2015-06-23 20:19:17 |
Message-ID: | 5589BF45.2030306@BlueTreble.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 6/22/15 11:59 PM, Fabien COELHO wrote:
>> which might not be helpful for cases when checkpoint could have
>> flushed soon-to-be-recycled buffers. I think flushing the sorted
>> buffers w.r.t tablespaces is a good idea, but not giving any
>> preference to clock-sweep point seems to me that we would loose in
>> some cases by this new change.
>
> 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.
Other than that though, it is pretty orthogonal, so perhaps another
indication that the clock should be handled separately from both
backends and bgwriter...
--
Jim Nasby, Data Architect, Blue Treble Consulting, Austin TX
Data in Trouble? Get it in Treble! http://BlueTreble.com
From | Date | Subject | |
---|---|---|---|
Next Message | Merlin Moncure | 2015-06-23 20:22:21 | Re: proposal: row_to_array function |
Previous Message | Jim Nasby | 2015-06-23 19:57:52 | Re: proposal: row_to_array function |