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

Browse pgsql-hackers by date

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