DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:cc:content-type:content-transfer-encoding;
	b=SL+Dk+gp77uUMK/pyKI97Lmw5kStdgOuvo2y6e8EYuZ0X5yUOnHrwd6HnPu2cHtQa0
	X6Dp8xjVwAVz57LjMNcy0foO5dzrfyckq1ddaN35gmzF/BneYZ/I71SjiLgJDYfpCpo0
	WHLZjO+NWduzMHphPPydAuipRPXJi+Nul1FwI=
MIME-Version: 1.0
In-Reply-To: <4D228247.9020901@2ndquadrant.com>
References: <F13DEE85-D114-4761-AD4D-924F1A741ACC@inomial.com>
	<m38vzl6z17.fsf@jhcloos.com> <4D0EFC02.7040004@vmsinfo.com>
	<5509F55C-FA66-4813-89C3-B2E62F6E8F49@Nasby.net>
	<4D21F68E.9070004@vmsinfo.com>
	<EF37296944B47C40ADDCCB7BFD6289FE046EED92AB@EMASC201VS01.exchad.jpmchase.net>
	<4D228247.9020901@2ndquadrant.com>
Date: Tue, 4 Jan 2011 11:48:59 -0500
Message-ID: <AANLkTimtMDF8GiJuEBm+k-RZNBpUdVxknuenHX=cAMNd@mail.gmail.com>
Subject: Re: Question: BlockSize > 8192 with FusionIO
From: Merlin Moncure <mmoncure@gmail.com>
To: Greg Smith <greg@2ndquadrant.com>
Cc: "Strange, John W" <john.w.strange@jpmchase.com>,
	"pgsql-performance@postgresql.org" <pgsql-performance@postgresql.org>
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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 probl=
em
> working against you here is how WAL data is used to protect against parti=
al
> database writes. =A0See the documentation for full_page_writes at
> http://www.postgresql.org/docs/current/static/runtime-config-wal.html
> =A0Because full size copies of the blocks have to get written there, atte=
mpts
> to chunk writes into larger pieces end up requiring a correspondingly lar=
ger
> volume of writes to protect against partial writes to those pages. =A0You
> 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 wit=
h
> 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