| From: | Florian Weimer <fweimer(at)bfk(dot)de> |
|---|---|
| To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
| Cc: | "Luke Lonergan" <LLonergan(at)greenplum(dot)com>, "Grzegorz Jaskiewicz" <gj(at)pointblue(dot)com(dot)pl>, "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 09:20:18 |
| Message-ID: | 82fy8k59nx.fsf@mid.bfk.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
* Tom Lane:
> 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.
Uhm, if it's not in the cache, you typically need to evict some cache
lines to make room for the data, so I'd expect an indirect performance
hit. I could be mistaken, though.
--
Florian Weimer <fweimer(at)bfk(dot)de>
BFK edv-consulting GmbH http://www.bfk.de/
Kriegsstraße 100 tel: +49-721-96201-1
D-76133 Karlsruhe fax: +49-721-96201-99
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Hannu Krosing | 2007-03-05 09:41:49 | Re: Bug: Buffer cache is not scan resistant |
| Previous Message | Tom Lane | 2007-03-05 09:15:45 | Re: Bug: Buffer cache is not scan resistant |