From: | Greg Stark <stark(at)mit(dot)edu> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Limiting setting of hint bits by read-only queries; vacuum_delay |
Date: | 2013-03-25 12:21:38 |
Message-ID: | CAM-w4HMELHt+33MFE4iaK9dQqFnbFbHwXVmTH-hhTn1Hx5FLoQ@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Mon, Mar 25, 2013 at 2:50 AM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> The idea I was thinking about is refactoring the background writer's role in
> hint bit maintenance
A good first step might be to separate the "dirty" bit into two bits.
"mandatory dirty" and "optional dirty". (Or maybe "hard dirty" and
"soft dirty"). Hint bit updates could set the latter and then some
later policy decision could be made about whether to bother writing
out the buffer if it's only optionally dirty.
My personal suspicion is that the right policy will look something
like writing out 1/nth of the hint bit dirtied pages. Where n is
something like MaxTuplesPerPage or perhaps the actual number of tuples
per page. And perhaps that should only happen if there are any
mandatory dirty pages waiting to be written or something like that.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Amit Kapila | 2013-03-25 12:22:11 | Re: Proposal for Allow postgresql.conf values to be changed via SQL [review] |
Previous Message | Heikki Linnakangas | 2013-03-25 09:23:47 | Re: backward incompatible pg_basebackup and pg_receivexlog |