Re: BLCKSZ fun facts - Mailing list pgsql-hackers

From Kenneth Marshall
Subject Re: BLCKSZ fun facts
Date
Msg-id 20061128171527.GC20126@it.is.rice.edu
Whole thread Raw
In response to Re: BLCKSZ fun facts  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-hackers
On Tue, Nov 28, 2006 at 12:08:59PM -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e@gmx.net> writes:
> > Aside from that my pgbench testing clearly shows that block sizes larger 
> > than 2048 become progressively slower.  Go figure.
> 
> I believe that pgbench only stresses the "small writes" case, so
> perhaps this result isn't too surprising.  You'd want to look at a mix
> of small and bulk updates before drawing any final conclusions.
> 
>             regards, tom lane
> 
It has certainly been the case in every benchmark that I have ever seen
from RAID controllers to filesystem layouts that the sweet spot in the
trade-offs between small and large blocksizes was 8k. Other reasons
such as the need to cover a very large filespace of support many small
<< 1024 byte files, could tip the scales towards larger or smaller
blocksizes. 

Ken


pgsql-hackers by date:

Previous
From: Tom Lane
Date:
Subject: Order of checking for readline support libraries
Next
From: Tom Lane
Date:
Subject: Re: Shutting down a warm standby database in