Shridhar Daithankar wrote:
> 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. #
#================================================== JanWieck@Yahoo.com #
