Re: survey of WAL blocksize changes - Mailing list pgsql-hackers

From Tom Lane
Subject Re: survey of WAL blocksize changes
Date
Msg-id 22407.1243472945@sss.pgh.pa.us
Whole thread Raw
In response to Re: survey of WAL blocksize changes  (Mark Wong <markwkm@gmail.com>)
Responses Re: survey of WAL blocksize changes  (Greg Stark <greg.stark@enterprisedb.com>)
Re: survey of WAL blocksize changes  (Simon Riggs <simon@2ndQuadrant.com>)
List pgsql-hackers
Mark Wong <markwkm@gmail.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


pgsql-hackers by date:

Previous
From: "Kevin Grittner"
Date:
Subject: Re: User-facing aspects of serializable transactions
Next
From: "Marc G. Fournier"
Date:
Subject: Re: PostgreSQL Developer meeting minutes up