On Wed, 2009-05-27 at 17:51 -0700, Mark Wong wrote:
> On Wed, May 27, 2009 at 1:46 AM, Simon Riggs wrote:
> >
> > On Tue, 2009-05-26 at 19:51 -0700, Mark Wong wrote:
> >> It appears for this workload using a 16KB or 32KB gets more than 4%
> >> throughput improvement, but some of that could be noi
On Wed, 2009-05-27 at 21:09 -0400, Tom Lane wrote:
> 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:
Two performance effects would be sufficient to explain the results.
* Optimal p
I find it pretty hard to beleive that 8k is precisely where a drop in
performance shows up unless there's some peculiar reason.
The only peculiar reason I can imagine is full page writes. If the
dbt2 workload is modifying already full pages then the full page
writes will always be just shy
Mark Wong 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%
On Wed, May 27, 2009 at 1:46 AM, Simon Riggs wrote:
>
> On Tue, 2009-05-26 at 19:51 -0700, Mark Wong wrote:
>> It appears for this workload using a 16KB or 32KB gets more than 4%
>> throughput improvement, but some of that could be noise.
>
> The baseline appears to have a significant jump in txn
On Wednesday 27 May 2009 05:51:05 Mark Wong wrote:
> BS notpm % Change from default
> -- - --
> 1 14673 -4.8%
> 2 15864 2.9%
> 4 15774 2.3%
> 8 15413 (default)
> 16 16118 4.6%
> 32 16051 4.1%
> 64 14874 -3.5%
This means that both somewhat larger and somewhat smaller than 8 give bet
Why on earth would there be a dip precisely at 8k with both smaller
and larger block sizes being faster??
--
Greg
On 27 May 2009, at 03:51, Mark Wong wrote:
Hi all,
A long long time ago (in 2004) I ran a series of tests surveying the
results of changing BLCKSZ when it was used for both th
On Tue, 2009-05-26 at 19:51 -0700, Mark Wong wrote:
> It appears for this workload using a 16KB or 32KB gets more than 4%
> throughput improvement, but some of that could be noise.
The baseline appears to have a significant jump in txn response time
after 77 mins on the baseline test. I think yo
Hi all,
A long long time ago (in 2004) I ran a series of tests surveying the
results of changing BLCKSZ when it was used for both the WAL logs and
the rest of the database system:
http://archives.postgresql.org/pgsql-hackers/2004-03/msg01194.php
Now more than 5 years later and now being able to
