Re: [PATCHES] scan_recycle_buffers - Mailing list pgsql-hackers

From Simon Riggs
Subject Re: [PATCHES] scan_recycle_buffers
Date
Msg-id 1173564652.3641.439.camel@silverbirch.site
Whole thread Raw
List pgsql-hackers
On Sat, 2007-03-10 at 23:26 +1300, Mark Kirkwood wrote:
> Simon Riggs wrote:
> > New patch enclosed, implementation as you've requested.
> >
> > Not ready to apply yet, but good for testing.
> >
>
> A quick test using the setup for "Buffer cache is not scan resistant"
> thread:
>
> Firstly vanilla 8.3 from 20070310:
>
> Shared Buffers  Elapsed  vmstat IO rate
> --------------  -------  --------------
> 400MB           101 s    122 MB/s
> 128KB            79 s    155 MB/s  [1]
>
> Now apply cycle scan v2:
>
> Shared Buffers  Scan_recycle_buffers Elapsed  vmstat IO rate
> --------------  -------------------- -------  -------------
> 400MB           0                    101 s    122 MB/s
> 400MB           8                    78 s     155 MB/s
> 400MB           16                   77 s     155 MB/s
> 400MB           32                   78 s     155 MB/s
> 400MB           64                   82 s     148 MB/s
> 400MB           128                  93 s     128 MB/s
>
> Certainly seems to have the desired effect!
>
> Cheers
>
> Mark
>
> [1] I'm not seeing 166 MB/s like previous 8.2.3 data, however 8.3 PGDATA
> is located further toward the end of the disk array - which I suspect is
> limiting the IO rate a little.

That's good news, thanks very much for testing that.

Before we can claim success, we need a few more tests on VACUUM, COPY
and a null test case to show it doesn't effect typical workloads, except
to improve vacuuming. I'll see if we can arrange those at EDB on a
reasonable size system.

--
  Simon Riggs
  EnterpriseDB   http://www.enterprisedb.com



pgsql-hackers by date:

Previous
From: "Pavel Stehule"
Date:
Subject: Re: what can be wrong? backport plpgpsm to 8.1
Next
From: Michael Fuhr
Date:
Subject: Re: Race condition in pg_database_size()