Re: limiting hint bit I/O - Mailing list pgsql-hackers

From Robert Haas
Subject Re: limiting hint bit I/O
Date
Msg-id AANLkTimWjcYZrFgg_07s00CCgHabS8SvKfOtU2OJwqkw@mail.gmail.com
Whole thread Raw
In response to Re: limiting hint bit I/O  ("Kevin Grittner" <Kevin.Grittner@wicourts.gov>)
Responses Re: limiting hint bit I/O  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Sun, Jan 16, 2011 at 8:41 PM, Kevin Grittner
<Kevin.Grittner@wicourts.gov> wrote:
> Robert Haas  wrote:
\>> I think you may be confused about what the patch does - currently,
>> pages with hint bit changes are considered dirty, period.
>> Therefore, they are written whenever any other dirty page would be
>> written: by the background writer cleaning scan, at checkpoints,
>> and when a backend must write a dirty buffer before reallocating it
>> to hold a different page. The patch keeps the first of these and
>> changes the second two
>
> No, I understood that.  I'm just concerned that if you eliminate the
> other two, we may be recomputing visibility based on clog often
> enough to kill performance.
>
> In other words, I'm asking that you show that the other two methods
> aren't really needed for decent overall performance.

Admittedly I've only done one test, but on the basis of that test I'd
say the other two methods ARE really needed for decent overall
performance.  I think it'd be interesting to see this tested on a
machine with large shared buffers, where the background writer might
succeed in cleaning a higher fraction of the pages before the bulk
read buffer access strategy starts recycling buffers.  But I'm not
very optimistic.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: Spread checkpoint sync
Next
From: Robert Haas
Date:
Subject: Re: Patch to add a primary key using an existing index