From: | Scott Marlowe <scott(dot)marlowe(at)gmail(dot)com> |
---|---|
To: | Greg Smith <greg(at)2ndquadrant(dot)com> |
Cc: | Josh Berkus <josh(at)agliodbs(dot)com>, pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Testing Sandforce SSD |
Date: | 2010-08-03 00:12:41 |
Message-ID: | AANLkTikQ=CUSoRy+MxYA2TAfk2hdipA4Uz_qYXyu+yhR@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Mon, Aug 2, 2010 at 6:07 PM, Greg Smith <greg(at)2ndquadrant(dot)com> wrote:
> Josh Berkus wrote:
>>
>> That doesn't make much sense unless there's some special advantage to a
>> 4K blocksize with the hardware itself.
>
> Given that pgbench is always doing tiny updates to blocks, I wouldn't be
> surprised if switching to smaller blocks helps it in a lot of situations if
> one went looking for them. Also, as you point out, pgbench runtime varies
> around wildly enough that 10% would need more investigation to really prove
> that means something. But I think Yeb has done plenty of investigation into
> the most interesting part here, the durability claims.
Running the tests for longer helps a lot on reducing the noisy
results. Also letting them runs longer means that the background
writer and autovacuum start getting involved, so the test becomes
somewhat more realistic.
From | Date | Subject | |
---|---|---|---|
Next Message | Robert Haas | 2010-08-03 02:48:52 | Re: Questions on query planner, join types, and work_mem |
Previous Message | Greg Smith | 2010-08-03 00:07:43 | Re: Testing Sandforce SSD |