Skip site navigation (1) Skip section navigation (2)

Re: BLCKSZ fun facts

From: Kenneth Marshall <ktm(at)it(dot)is(dot)rice(dot)edu>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Peter Eisentraut <peter_e(at)gmx(dot)net>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: BLCKSZ fun facts
Date: 2006-11-28 17:15:27
Message-ID: 20061128171527.GC20126@it.is.rice.edu (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
On Tue, Nov 28, 2006 at 12:08:59PM -0500, Tom Lane wrote:
> Peter Eisentraut <peter_e(at)gmx(dot)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

In response to

pgsql-hackers by date

Next:From: Jeff DavisDate: 2006-11-28 17:30:15
Subject: Re: Integrating Replication into Core
Previous:From: Tom LaneDate: 2006-11-28 17:08:59
Subject: Re: BLCKSZ fun facts

pgsql-patches by date

Next:From: Kevin GrittnerDate: 2006-11-28 19:27:55
Subject: pg_dump -t broken for mixed case table names in beta3?
Previous:From: Tom LaneDate: 2006-11-28 17:08:59
Subject: Re: BLCKSZ fun facts

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group