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
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers pgsql-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

Browse pgsql-hackers by date

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

Browse pgsql-patches by date

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