Re: Bug: Buffer cache is not scan resistant

From: "Luke Lonergan" <LLonergan(at)greenplum(dot)com>
To: "Tom Lane" <tgl(at)sss(dot)pgh(dot)pa(dot)us>, "Gavin Sherry" <swm(at)alcove(dot)com(dot)au>
Cc: "Mark Kirkwood" <markir(at)paradise(dot)net(dot)nz>, "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:30:13
Message-ID: C3E62232E3BCF24CBA20D72BFDCB6BF802CFC0C2@MI8NYCMAIL08.Mi8.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Hi Tom,

> Now this may only prove that the disk subsystem on this
> machine is too cheap to let the system show any CPU-related
> issues.

Try it with a warm IO cache. As I posted before, we see double the
performance of a VACUUM from a table in IO cache when the shared buffer
cache isn't being polluted. The speed with large buffer cache should be
about 450 MB/s and the speed with a buffer cache smaller than L2 should
be about 800 MB/s.

The real issue here isn't the L2 behavior, though that's important when
trying to reach very high IO speeds, the issue is that we're seeing the
buffer cache pollution in the first place. When we instrument the
blocks selected by the buffer page selection algorithm, we see that they
iterate sequentially, filling the shared buffer cache. That's the
source of the problem here.

Do we have a regression test somewhere for this?

- Luke

In response to

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2007-03-05 08:45:17 Re: Bug: Buffer cache is not scan resistant
Previous Message Luke Lonergan 2007-03-05 08:28:49 Re: Bug: Buffer cache is not scan resistant