Re: Clock sweep not caching enough B-Tree leaf pages?

From: Robert Haas <robertmhaas(at)gmail(dot)com>
To: Andres Freund <andres(at)2ndquadrant(dot)com>
Cc: Merlin Moncure <mmoncure(at)gmail(dot)com>, Peter Geoghegan <pg(at)heroku(dot)com>, Pg Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Clock sweep not caching enough B-Tree leaf pages?
Date: 2014-04-16 14:29:29
Message-ID: CA+TgmobDOip4EqS7pk9h-pXGpoy+s6xpWh-uM1kotek3Qdj05w@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

On Wed, Apr 16, 2014 at 9:35 AM, Andres Freund <andres(at)2ndquadrant(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Robert Haas 2014-04-16 14:37:12 Re: bgworker crashed or not?
Previous Message Marco Atzeri 2014-04-16 14:12:11 Re: test failure on latest source