"Luke Lonergan" <[EMAIL PROTECTED]> 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 ---------------------------(end of broadcast)--------------------------- TIP 5: don't forget to increase your free space map settings
