On Mon, Jan 3, 2011 at 9:13 PM, Greg Smith <greg@2ndquadrant.com> wrote:
> 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.
most flash drives, especially mlc flash, use huge blocks anyways on
physical level. the numbers claimed here
(http://www.fusionio.com/products/iodrive/) (141k write iops) are
simply not believable without write buffering. i didn't see any note
of how fault tolerance is maintained through the buffer (anyone
know?).
assuming they do buffer, i would expect a smaller blocksize would be
better/easier on the ssd, since this would mean less gross writing,
higher maximum throughput, and less wear and tear on the flash; the
advantages of the larger blocksize are very hardware driven and
already managed by the controller.
if they don't buffer (again, I'm very skeptical this is the case), a
larger block size, possibly even a much larger block size (like 256k)
would be an interesting test. i'm pretty skeptical about the fusion
i/o product generally, because i don't think the sata interface is a
bottleneck save for read caching, and the o/s is already buffering
reads. the storage medium is still the bottleneck for the most part
(even if it's much faster at certain things). note fusion is still
useful for some things, but the nice is narrower than it looks on the
surface.
merlin