On Wed, Apr 15, 2015 at 5:06 PM, Greg Stark <st...@mit.edu> wrote: > This is my point though (you're right that "flushed" isn't always the > same as eviction but that's not the important point here). Right now > we only demote when we consider buffers for eviction. But we promote > when we pin buffers. Those two things aren't necessarily happening at > the same rate and in fact are often orders of magnitude different.
I am absolutely, positively, violently in 100% agreement with this. I have made the same point before, but it sure is nice to hear someone else thinking about it the same way. > So > it makes sense that we end up with a lot of buffers promoted all the > way to the most recently used ntile and then have to do n passes > around the clock and have no good information about which buffer to > evict. Right. > What I'm saying is that we should demote a buffer every time we > promote a buffer. So every time we pin a buffer we should advance the > clock a corresponding amount. I know I'm being intentionally vague > about what the corresponding amount is.) The important thing is that > the two should be tied together. Yes, absolutely. If you tilt your head the right way, my proposal of limiting the number of promotions per clock sweep has the effect of tying buffer demotion and buffer promotion together much more tightly than is the case right now. You are limited to 2 promotions per demotion; and practically speaking not all buffers eligible to be promoted will actually get accessed, so the number of promotions per demotion will in reality be somewhere between 0 and 2. Ideally it would be exactly 1, but 1 +/- 1 is still a tighter limit than we have at present. Which is not to say there isn't some other idea that is better still. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
