Re: scan_recycle_buffers - Mailing list pgsql-patches

From Mark Kirkwood
Subject Re: scan_recycle_buffers
Date
Msg-id 45F287D1.1070305@paradise.net.nz
Whole thread Raw
In response to Re: scan_recycle_buffers  ("Simon Riggs" <simon@2ndquadrant.com>)
Responses Re: scan_recycle_buffers  ("Simon Riggs" <simon@2ndquadrant.com>)
List pgsql-patches
Simon Riggs wrote:
> On Sat, 2007-03-10 at 07:59 +0000, Simon Riggs wrote:
>> On Fri, 2007-03-09 at 18:05 -0500, Tom Lane wrote:
>>> "Simon Riggs" <simon@2ndquadrant.com> writes:
>>>> On Fri, 2007-03-09 at 16:45 -0500, Tom Lane wrote:
>>>>> We do that anyway; but certainly Simon's patch ought not be injecting
>>>>> an additional one.
>>>> It should be possible to pass that down from the planner to the
>>>> executor, in certain cases.
>>> Huh?  See HeapScanDesc->rs_nblocks.
>> Many thanks.
>
> 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.

pgsql-patches by date:

Previous
From: "Simon Riggs"
Date:
Subject: Re: scan_recycle_buffers
Next
From: "Pavel Stehule"
Date:
Subject: simply custom variables protection