Message-ID: <4BE9FDFC.40401@agliodbs.com>
Date: Tue, 11 May 2010 18:01:48 -0700
From: Josh Berkus <josh@agliodbs.com>
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US;
	rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2
MIME-Version: 1.0
To: postgres performance list <pgsql-performance@postgresql.org>
Subject: Re: 8K recordsize bad on ZFS?
References: <4BE4ABC9.6040106@agliodbs.com>
	<AANLkTim6rVYoAZaspbEnsyE9LPmWGXWe4Van40Snldoj@mail.gmail.com>
	<4BE852CE.9020802@agliodbs.com> <hs9ltj$c8q$1@dough.gmane.org>
	<4BE85ED3.4010008@agliodbs.com>
	<j2w407d949e1005101301r9a1c0f7dk9995279fcd7c26a8@mail.gmail.com>
	<4BE877BE.8000908@agliodbs.com>
	<20100511134138.GB14663@oak.highrise.ca>
In-Reply-To: <20100511134138.GB14663@oak.highrise.ca>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit


> Sure, but bulk load + reandom selects is going to *guarentee*
> fragmentatioon on a COW system (like ZFS, BTRFS, etc) as the selects
> start to write out all the hint-bit-dirtied blocks in random orders...
> 
> i.e. it doesn't take long to make an originally nicely continuous block
> random....

I'm testing with DD and Bonnie++, though, which create their own files.

For that matter, running an ETL procedure with a newly created database
on both recordsizes was notably (2.5x) faster on the 128K system.

So I don't think fragmentation is the difference.

-- 
                                  -- Josh Berkus
                                     PostgreSQL Experts Inc.
                                     http://www.pgexperts.com