Strange, John W wrote:
> Has anyone had a chance to recompile and try larger a larger blocksize than 8192 with pSQL 8.4.x?
While I haven't done the actual experiment you're asking about, the
problem working against you here is how WAL data is used to protect
against partial database writes. See the documentation for
full_page_writes at
http://www.postgresql.org/docs/current/static/runtime-config-wal.html
Because full size copies of the blocks have to get written there,
attempts to chunk writes into larger pieces end up requiring a
correspondingly larger volume of writes to protect against partial
writes to those pages. You might get a nice efficiency gain on the read
side, but the situation when under a heavy write load (the main thing
you have to be careful about with these SSDs) is much less clear.
I wouldn't draw any conclusions whatsoever from what fio says about
this; it's pretty useless IMHO for simulating anything like a real
database workload. I don't even use that utility anymore, as I found it
just wasted my time compared with moving straight onto something that
tries to act to like a database application simulation. You might try
running pgbench with the database scale set to large enough that the
resulting database is large relative to total system RAM instead.
P.S. Make sure you put the FusionIO drives under a heavy write load and
power down the server hard, so you can see what happens if there's a
real-world crash. Recovery time to remount the drives in that situation
is the main drawback of their design. It does the right thing to
protect your data as far as I know, but the recovery can be quite time
intensive.
--
Greg Smith 2ndQuadrant US greg@2ndQuadrant.com Baltimore, MD
PostgreSQL Training, Services and Support www.2ndQuadrant.us
"PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books