Jan Wieck wrote:
> Jan Wieck wrote:
>> Jan Wieck wrote:
>>> I will follow up shortly with an approach that integrates Tom's delay
>>> mechanism plus my first READ_BY_VACUUM hack into one combined experiement.
>> the attached patch contains the 3 already discussed and one additional
but I'm getting closer.
I guess I polluted the list enough. The latest patch is now here:
This one now correctly keeps T1len+B1len at about the number of buffers,
which is half the directory size. The former versions favored T1 too much.
It also contains the starting work of the discussed background buffer
writer. Thus far, the BufferSync() done at a checkpoint only writes out
all dirty blocks in their LRU order and over a configurable time
(lazy_checkpoint_time in seconds). But that means at least, while the
checkpoint is running the backends should not need to flush dirty
buffers as well, since all the candidates they get for replacement are
clean. My plan is to create another background process very similar to
the checkpointer and to let that run forever basically looping over that
BufferSync() with a bool telling that it's the bg_writer.
# It's easier to get forgiveness for being wrong than for being right. #
# Let's break this rule - forgive me. #
#================================================== JanWieck(at)Yahoo(dot)com #
In response to
pgsql-hackers by date
|Next:||From: scott.marlowe||Date: 2003-11-04 20:41:30|
|Subject: Re: Experimental patch for inter-page delay in VACUUM |
|Previous:||From: Andrew Dunstan||Date: 2003-11-04 20:15:10|
|Subject: Re: Open Sourcing pgManage|