Re: Experimental ARC implementation
От | Jan Wieck |
---|---|
Тема | Re: Experimental ARC implementation |
Дата | |
Msg-id | 3FA80E97.1070608@Yahoo.com обсуждение исходный текст |
Ответ на | Re: Experimental ARC implementation (Jan Wieck <JanWieck@Yahoo.com>) |
Ответы |
Re: Experimental ARC implementation
|
Список | pgsql-hackers |
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. >> >> 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. # #================================================== JanWieck@Yahoo.com #
В списке pgsql-hackers по дате отправления: