| From: | Gavin Sherry <swm(at)alcove(dot)com(dot)au> |
|---|---|
| To: | Mark Kirkwood <markir(at)paradise(dot)net(dot)nz> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Luke Lonergan <llonergan(at)greenplum(dot)com>, 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 05:16:44 |
| Message-ID: | Pine.LNX.4.58.0703051614070.19071@linuxworld.com.au |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Mon, 5 Mar 2007, Mark Kirkwood wrote:
> To add a little to this - forgetting the scan resistant point for the
> moment... cranking down shared_buffers to be smaller than the L2 cache
> seems to help *any* sequential scan immensely, even on quite modest HW:
>
> e.g: PIII 1.26Ghz 512Kb L2 cache, 2G ram,
>
> SELECT count(*) FROM lineitem (which is about 11GB) performance:
>
> Shared_buffers Elapsed
> -------------- -------
> 400MB 101 s
> 128KB 74 s
>
> When I've profiled this activity, I've seen a lot of time spent
> searching for/allocating a new buffer for each page being fetched.
> Obviously having less of them to search through will help, but having
> less than the L2 cache-size worth of 'em seems to help a whole lot!
Could you demonstrate that point by showing us timings for shared_buffers
sizes from 512K up to, say, 2 MB? The two numbers you give there might
just have to do with managing a large buffer.
Thanks,
Gavin
| From | Date | Subject | |
|---|---|---|---|
| Next Message | William ZHANG | 2007-03-05 05:34:48 | Re: ERROR: operator does not exist: integer !=- integer |
| Previous Message | Mark Kirkwood | 2007-03-05 05:03:54 | Re: Bug: Buffer cache is not scan resistant |