From: Andres Freund <andres@anarazel.de>
To: Greg Spiegelberg <gspiegelberg@gmail.com>
Cc: Greg Smith <greg@2ndquadrant.com>
Cc: Yeb Havinga <yebhavinga@gmail.com>
Cc: pgsql-performance@postgresql.org
Subject: Re: Testing Sandforce SSD
Date: Tue, 27 Jul 2010 00:28:04 +0200
Message-ID: <20100726222804.GA3054@anarazel.de> (raw)
In-Reply-To: <AANLkTimwAqzvWvSfscqDKJDG3Yod=6KQ6e0Xo+c+k6s=@mail.gmail.com>
References: <4C4A9452.9070100@gmail.com>
<4C4B1F84.5030306@2ndquadrant.com>
<4C4C83DF.3010703@gmail.com>
<4C4C8CCC.7080406@gmail.com>
<alpine.DEB.2.00.1007261045470.20471@aragorn.flymine.org>
<4C4D6396.5020707@gmail.com>
<4C4DAAE8.3060501@2ndquadrant.com>
<4C4DE50B.1060102@gmail.com>
<4C4DE5C9.8090004@2ndquadrant.com>
<AANLkTimwAqzvWvSfscqDKJDG3Yod=6KQ6e0Xo+c+k6s=@mail.gmail.com>
On Mon, Jul 26, 2010 at 03:23:20PM -0600, Greg Spiegelberg wrote:
> On Mon, Jul 26, 2010 at 1:45 PM, Greg Smith <greg@2ndquadrant.com> wrote:
> > Yeb Havinga wrote:
> >> I did some ext3,ext4,xfs,jfs and also ext2 tests on the just-in-memory
> >> read/write test. (scale 300) No real winners or losers, though ext2 isn't
> >> really faster and the manual need for fix (y) during boot makes it
> >> impractical in its standard configuration.
> >>
> >
> > That's what happens every time I try it too. The theoretical benefits of
> > ext2 for hosting PostgreSQL just don't translate into significant
> > performance increases on database oriented tests, certainly not ones that
> > would justify the downside of having fsck issues come back again. Glad to
> > see that holds true on this hardware too.
> I know I'm talking development now but is there a case for a pg_xlog block
> device to remove the file system overhead and guaranteeing your data is
> written sequentially every time?
For one I doubt that its a relevant enough efficiency loss in
comparison with a significantly significantly complex implementation
(for one you cant grow/shrink, for another you have to do more
complex, hw-dependent things like rounding to hardware boundaries,
page size etc to stay efficient) for another my experience is that at
a relatively low point XlogInsert gets to be the bottleneck - so I
don't see much point in improving at that low level (yet at least).
Where I would like to do some hw dependent measuring (because I see
significant improvements there) would be prefetching for seqscan,
indexscans et al. using blktrace... But I currently dont have the
time. And its another topic ;-)
Andres
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Reply to all the recipients using the --to and --cc options:
reply via email
To: pgsql-performance@postgresql.org
Cc: andres@anarazel.de, gspiegelberg@gmail.com, greg@2ndquadrant.com, yebhavinga@gmail.com
Subject: Re: Testing Sandforce SSD
In-Reply-To: <20100726222804.GA3054@anarazel.de>
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox