Re: Bgwriter strategies - Mailing list pgsql-hackers

From Gregory Stark
Subject Re: Bgwriter strategies
Date
Msg-id 87bqepy0ne.fsf@oxford.xeocode.com
Whole thread Raw
In response to Re: Bgwriter strategies  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
"Tom Lane" <tgl@sss.pgh.pa.us> writes:

>> That would be overly aggressive on a workload that's steady on average, 
>> but consists of small bursts. Like this: 0 0 0 0 100 0 0 0 0 100 0 0 0 0 
>> 100. You'd end up writing ~100 pages on every bgwriter round, but you 
>> only need an average of 20 pages per round.
>
> No, you wouldn't be *writing* that many, you'd only be keeping that many
> *clean*; which only costs more work if any of them get re-dirtied
> between writing and use.  Which is a fairly small probability if we're
> talking about a small difference in the number of buffers to keep clean.
> So I think the average number of writes is hardly different, it's just
> that the backends are far less likely to have to do any of them.

Well Postgres's hint bits tends to redirty pages precisely once at just about
the time when they're ready to be paged out. But I think there are things we
can do to tackle that head-on. 

Bgwriter could try to set hint bits before cleaning these pages for example.
Or we could elect in selected circumstances not to write out a page that is
hint-bit-dirty-only. Or some combination of those options depending on the
circumstances. Figuring out the circumstances is the hard part.

--  Gregory Stark EnterpriseDB          http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: Updated tsearch documentation
Next
From: Tom Lane
Date:
Subject: Re: usleep feature for pgbench