| From: | "Luke Lonergan" <LLonergan(at)greenplum(dot)com> |
|---|---|
| To: | "Mark Kirkwood" <markir(at)paradise(dot)net(dot)nz>, "Gavin Sherry" <swm(at)alcove(dot)com(dot)au> |
| Cc: | "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "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 10:04:09 |
| Message-ID: | C3E62232E3BCF24CBA20D72BFDCB6BF802CFC0D7@MI8NYCMAIL08.Mi8.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi Mark,
> lineitem has 1535724 pages (11997 MB)
>
> Shared Buffers Elapsed IO rate (from vmstat)
> -------------- ------- ---------------------
> 400MB 101 s 122 MB/s
>
> 2MB 100 s
> 1MB 97 s
> 768KB 93 s
> 512KB 86 s
> 256KB 77 s
> 128KB 74 s 166 MB/s
>
> I've added the observed IO rate for the two extreme cases
> (the rest can be pretty much deduced via interpolation).
>
> Note that the system will do about 220 MB/s with the now
> (in)famous dd test, so we have a bit of headroom (not too bad
> for a PIII).
What's really interesting: try this with a table that fits into I/O
cache (say half your system memory), and run VACUUM on the table. That
way the effect will stand out more dramatically.
- Luke
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Gregory Stark | 2007-03-05 10:10:47 | Re: Bug: Buffer cache is not scan resistant |
| Previous Message | Mark Kirkwood | 2007-03-05 10:00:13 | Re: Bug: Buffer cache is not scan resistant |