| From: | "Luke Lonergan" <LLonergan(at)greenplum(dot)com> |
|---|---|
| To: | "Gavin Sherry" <swm(at)alcove(dot)com(dot)au>, "Mark Kirkwood" <markir(at)paradise(dot)net(dot)nz> |
| 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 05:52:53 |
| Message-ID: | C3E62232E3BCF24CBA20D72BFDCB6BF802CFC0AF@MI8NYCMAIL08.Mi8.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Gavin, Mark,
> 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.
I suggest two experiments that we've already done:
1) increase shared buffers to double the L2 cache size, you should see
that the behavior reverts to the "slow" performance and is constant at
larger sizes
2) instrument the calls to BufferGetPage() (a macro) and note that the
buffer block numbers returned increase sequentially during scans of
tables larger than the buffer size
- Luke
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Tom Lane | 2007-03-05 06:25:42 | Re: Bug: Buffer cache is not scan resistant |
| Previous Message | William ZHANG | 2007-03-05 05:34:48 | Re: ERROR: operator does not exist: integer !=- integer |