Robert, Andres, * Andres Freund (and...@anarazel.de) wrote: > On 2016-04-12 14:29:10 -0400, Robert Haas wrote: > > On Wed, Apr 6, 2016 at 6:57 AM, Andres Freund <and...@anarazel.de> wrote: > > That does not seem like a good idea from here. One of the ideas I > > still want to explore at some point is having a background process > > identify the buffers that are just about to be evicted and stick them > > on the freelist so that the backends don't have to run the clock sweep > > themselves on a potentially huge number of buffers, at perhaps > > substantial CPU cost. Amit's last attempt at this didn't really pan > > out, but I'm not convinced that the approach is without merit. > > FWIW, I've posted an implementation of this in the checkpoint flushing > thread; I saw quite substantial gains with it. It was just entirely > unrealistic to push that into 9.6.
That is fantastic to hear and I certainly agree that we should be working on that approach. > > And, on the other hand, if we don't do something like that, it will be > > quite an exceptional case to find anything on the free list. Doing it > > just to speed up developer benchmarking runs seems like the wrong > > idea. > > I don't think it's just developer benchmarks. I've seen a number of > customer systems where significant portions of shared buffers were > unused due to this. Ditto. I agree that we should be smarter when we have a bunch of free shared_buffers space and we're doing sequential work. I don't think we want to immediately grab all that free space for the sequential work but perhaps there's a reasonable heuristic we could use- such as if the free space available is twice what we expect our sequential read to be, then go ahead and load it into shared buffers? The point here isn't to get rid of the ring buffers but rather to use the shared buffer space when we have plenty of it and there isn't contention for it. Thanks! Stephen
signature.asc
Description: Digital signature
