pg.ddx.io  pgsql-performance@postgresql.org mailing list archive  

help / color / mirror / Atom feed
From: Greg Smith <gsmith@gregsmith.com>
To: pgsql-performance@postgresql.org
Subject: Re: RAID arrays and performance
Date: Wed, 5 Dec 2007 01:47:04 -0500 (EST)
Message-ID: <Pine.GSO.4.64.0712050058250.22332@westnet.com> (raw)
In-Reply-To: <4755F6E7.2090701@mark.mielke.cc>
References: <Pine.LNX.4.58.0712041213490.3731@aragorn.flymine.org>
	<87lk8aiqf3.fsf@oxford.xeocode.com>
	<Pine.LNX.4.58.0712041247540.3731@aragorn.flymine.org>
	<475559F4.7060104@mark.mielke.cc>
	<Pine.LNX.4.58.0712041349380.3731@aragorn.flymine.org>
	<4755648C.90905@mark.mielke.cc>
	<87fxyiik94.fsf@oxford.xeocode.com>
	<Pine.LNX.4.58.0712041522320.3731@aragorn.flymine.org>
	<47557519.6090506@mark.mielke.cc>
	<47557872.1000105@mansionfamily.plus.com>
	<47557B12.5040809@mark.mielke.cc>
	<4755B51E.5040503@mansionfamily.plus.com>
	<4755D15F.7080400@mark.mielke.cc>
	<4755E9A7.7060906@mansionfamily.plus.com>
	<4755F6E7.2090701@mark.mielke.cc>

On Tue, 4 Dec 2007, Mark Mielke wrote:

>> This is bikeshed land, right?
> I am only interested by juicy projects that have a hope of success. This 
> subject does interest me - I am hoping my devil's advocate participation 
> encourages people to seek a practical implementation that will benefit me.

Nah, you're both in bikeshed land.  Ultimately this feature is going to 
get built out in a way that prioritizes as much portability as is possible 
while minimizing the impact on existing code.  The stated PostgreSQL bias 
is that async-I/O is not worth the trouble until proven otherwise: 
http://www.postgresql.org/docs/faqs.FAQ_DEV.html#item1.14

That's why Greg Stark is busy with low-level tests of I/O options while 
you're arguing much higher level details.  Until you've got some 
benchmarks in this specific area to go by, you can talk theory all day and 
not impact what implementation will actually get built one bit.

As an example of an area you've already brought up where theory and 
benchmarks clash violently, the actual situation with NCQ on SATA drives 
has been heavily blurred because of how shoddy some manufacturer's NCQ 
implementation are.  Take a look at the interesting thread on this topic 
at http://lkml.org/lkml/2007/4/3/159 to see what I'm talking about.  Even 
if you have an NCQ drive, and a version of Linux that supports it, and 
you've setup everything up right, you can still end up with unexpected 
performance regressions under some circumstances.  It's still the wild 
west with that technology.

--
* Greg Smith gsmith@gregsmith.com http://www.gregsmith.com Baltimore, MD



view thread (39+ messages)  latest in thread

Message-ID: <Pine.GSO.4.64.0712050058250.22332@westnet.com>
Permalink:  ../Pine.GSO.4.64.0712050058250.22332@westnet.com/
Also on:    postgresql.org/message-id/Pine.GSO.4.64.0712050058250.22332@westnet.com

 · 

reply
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: gsmith@gregsmith.com
  Subject: Re: RAID arrays and performance
  In-Reply-To: <Pine.GSO.4.64.0712050058250.22332@westnet.com>

* 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