Re: limiting hint bit I/O
Merlin Moncure <mmoncure@gmail.com>
From: Merlin Moncure <mmoncure@gmail.com>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Jim Nasby <jim@nasby.net>, Kevin Grittner <Kevin.Grittner@wicourts.gov>, Josh Berkus <josh@agliodbs.com>, Tom Lane <tgl@sss.pgh.pa.us>, pgsql-hackers Hackers <pgsql-hackers@postgresql.org>
Date: 2011-01-19T16:18:38Z
Lists: pgsql-hackers
On Wed, Jan 19, 2011 at 10:44 AM, Robert Haas <robertmhaas@gmail.com> wrote: > Here's a new version of the patch based on some experimentation with > ideas I posted yesterday. At least on my Mac laptop, this is pretty > effective at blunting the response time spike for the first table > scan, and it converges to steady-state after about 20 tables scans. > Rather than write every 20th page, what I've done here is make every > 2000'th buffer allocation grant an allowance of 100 "hint bit only" > writes. All dirty pages and the next 100 pages that are > dirty-only-for-hint-bits get written out. Then we stop writing the > dirty-only-for-hint-bits-pages until we get our next allowance of > writes. The idea is to try to avoid creating a lot of random writes > on each scan through the table. At least here, that seems to work > pretty well - the initial scan is only about 25% slower than the > steady state (rather than 6x or more slower). does this only impact the scan case? in oltp scenarios you want to write out the bits asap, i would imagine. what about time based flushing, so that only x dirty hint bit pages can be written out per time unit y? merlin