From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
---|---|
To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
Cc: | Jim Nasby <jim(at)nasby(dot)net>, Kevin Grittner <Kevin(dot)Grittner(at)wicourts(dot)gov>, Josh Berkus <josh(at)agliodbs(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-hackers Hackers <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: limiting hint bit I/O |
Date: | 2011-01-19 16:18:38 |
Message-ID: | AANLkTinLMoV8ib7qL37yFfsMLLpOaiH9-LDrcupaXbmQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, Jan 19, 2011 at 10:44 AM, Robert Haas <robertmhaas(at)gmail(dot)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
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2011-01-19 16:19:26 | Re: Re: [COMMITTERS] pgsql: Log replication connections only when log_connections is on |
Previous Message | Jan Urbański | 2011-01-19 16:07:19 | Re: pl/python refactoring |