On Wed, Apr 16, 2014 at 9:35 AM, Andres Freund <and...@2ndquadrant.com> wrote: > I think this is the wrong level to optimize things. Imo there's two > possible solutions (that don't exclude each other): > > * perform the clock sweep in one process so there's a very fast way to > get to a free buffer. Possibly in a partitioned way. > > * Don't take a global exclusive lock while performing the clock > sweep. Instead increase StrategyControl->nextVictimBuffer in chunks > under an exclusive lock, and then scan the potential victim buffers in > those chunks without a global lock held.
I definitely agree with both of these ideas. But isn't it sort of off-topic for this thread? There are two issues here: 1. Improving the rate at which we can evict buffers, which is what you're talking about here. 2. Improving the choice of which buffers we evict, which is what Peter's talking about, or at least what I think he's talking about. Those things are both important, but they're different, and I'm not sure that working on one precludes working on the other. There's certainly the potential for overlap, but not necessarily. -- 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
