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@xxxxxxxxxxxxxxx Baltimore, MD PostgreSQL Training, Services and Support www.2ndQuadrant.us "PostgreSQL 9.0 High Performance": http://www.2ndQuadrant.com/books -- Sent via pgsql-performance mailing list (pgsql-performance@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
