| From: | "Luke Lonergan" <LLonergan(at)greenplum(dot)com> |
|---|---|
| To: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Grzegorz Jaskiewicz" <gj(at)pointblue(dot)com(dot)pl> |
| Cc: | "PGSQL Hackers" <pgsql-hackers(at)postgresql(dot)org>, "Doug Rady" <drady(at)greenplum(dot)com>, "Sherry Moore" <sherry(dot)moore(at)sun(dot)com> |
| Subject: | Re: Bug: Buffer cache is not scan resistant |
| Date: | 2007-03-05 08:28:49 |
| Message-ID: | C3E62232E3BCF24CBA20D72BFDCB6BF802CFC0C0@MI8NYCMAIL08.Mi8.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
> 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.
http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/
25112.PDF
- Luke
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Luke Lonergan | 2007-03-05 08:30:13 | Re: Bug: Buffer cache is not scan resistant |
| Previous Message | Tom Lane | 2007-03-05 08:24:11 | Re: Bug: Buffer cache is not scan resistant |