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.
Okay,
the attached patch contains the 3 already discussed and one additional change.
Ooopsy
Ooops-2
but I'm getting closer.
I guess I polluted the list enough. The latest patch is now here:
http://developer.postgresql.org/~wieck/all_performance.v3.74.diff.gz
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.
Jan
-- #======================================================================# # It's easier to get forgiveness for being wrong than for being right. # # Let's break this rule - forgive me. # #================================================== [EMAIL PROTECTED] #
---------------------------(end of broadcast)--------------------------- TIP 9: the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
