"Luke Lonergan" <LLonergan@greenplum.com> writes:
>> So either way, it isn't in processor cache after the read.
>> So how can there be any performance benefit?
> It's the copy from kernel IO cache to the buffer cache that is L2
> sensitive. When the shared buffer cache is polluted, it thrashes the L2
> cache. When the number of pages being written to in the kernel->user
> space writes fits in L2, then the L2 lines are "written through" (see
> the link below on page 264 for the write combining features of the
> opteron for example) and the writes to main memory are deferred.
That makes absolutely zero sense. The data coming from the disk was
certainly not in processor cache to start with, and I hope you're not
suggesting that it matters whether the *target* page of a memcpy was
already in processor cache. If the latter, it is not our bug to fix.
> http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/
> 25112.PDF
Even granting that your conclusions are accurate, we are not in the
business of optimizing Postgres for a single CPU architecture.
regards, tom lane
