Jan Wieck wrote:
I committed the first part of the background writer process. We had a consensus on attempting to avoid write() calls from regular backends, but did no come to any conclusions what to do to force the kernel to actually do some IO.
Consequently, this patch is a separate process launched by postmaster, that periodically write()'s out "some" dirty buffers in LRU order. This causes the buffers returned for replacement (when a backend needs to read in a page) to be clean allways. The process does no sync(), fsync() or any other calls thus far. Nothing has changed in the checkpoint logic either.
Can we have some idea where to tweak sync routines for comparing results?
I mean I would like to run pgbench with same config all along and compare the performance difference between sync, fsync and fdatasync etc.
pgbench is actually a very bad example to test any cache strategy. Either 98% of your lookups result in cache hits, so basically your entire database is cached, or it doesn't fit and every cache strategy becomes useless. It doesn't have parts that fit and other parts that don't. I think pgbench doesn't use non-uniform random access as real world applications do (you have bestsellers and other items, you have frequent customers and once-a-year visitors). So it's very hard to get the system into a state where you have like 50% cache hitrate.
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 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
