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

Re: survey of WAL blocksize changes

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Mark Wong <markwkm(at)gmail(dot)com>
Cc: Simon Riggs <simon(at)2ndquadrant(dot)com>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: survey of WAL blocksize changes
Date: 2009-05-28 01:09:05
Message-ID: 22407.1243472945@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Mark Wong <markwkm(at)gmail(dot)com> writes:
> Oopsies.  I've rerun, but now that there is no dip, the average
> throughput still didn't change much:

> BS notpm % Change from default
> -- ----- ----------
>  1 14673 -5.1%
>  2 15864 2.7%
>  4 15774 2.1%
>  8 15454 (default)
> 16 16118 4.3%
> 32 16051 3.9%
> 64 14874 -3.8%

So, if we assume that these numbers are real and not artifacts, it seems
we have to postulate at least four distinct block-size-dependent
performance effects:

1. A strong penalty for smaller block sizes, which becomes dominant
below 2KB.

2. A strong penalty for larger block sizes, which becomes dominant
above 32KB.

3. A weak benefit for smaller block sizes, which is visible at 2-4KB
but fades away at 8KB.

4. A weak benefit for larger block sizes, which only becomes visible
above 8KB.

It's not too hard to believe any of those individually, and even to
think of plausible mechanisms.  But it seems a bit unlikely that effects
3 and 4 would exist but consistently cross over right at our traditional
choice of block size.

I'm suspecting that this curve is heavily dependent on details of the
DBT2 test and/or the hardware used.  It would be interesting to see if
anyone can replicate it using a different benchmark.

			regards, tom lane

In response to

Responses

pgsql-hackers by date

Next:From: Marc G. FournierDate: 2009-05-28 01:09:10
Subject: Re: PostgreSQL Developer meeting minutes up
Previous:From: Jeff DavisDate: 2009-05-28 01:08:00
Subject: Re: User-facing aspects of serializable transactions

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