From: =?iso-8859-1?q?C=E9dric_Villemain?= <cedric.villemain@dalibo.com>
Organization: dalibo.com
To: pgsql-performance@postgresql.org
Subject: Re: Fusion-io ioDrive
Date: Wed, 2 Jul 2008 15:36:06 +0200
User-Agent: KMail/1.9.9
Cc: "Jonah H. Harris" <jonah.harris@gmail.com>,
	"Jeffrey Baker" <jwbaker@gmail.com>
References: <fd145f7d0807011718j3c9c4462qe9f6d2a1efebe7b7@mail.gmail.com>
	<36e682920807020441h11abd344j9c510722189cb3a2@mail.gmail.com>
In-Reply-To: <36e682920807020441h11abd344j9c510722189cb3a2@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart3318876.HmZrABPE6N";
	protocol="application/pgp-signature"; micalg=pgp-sha1
Content-Transfer-Encoding: 7bit
Message-Id: <200807021536.11726.cedric.villemain@dalibo.com>

--nextPart3318876.HmZrABPE6N
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline

Le Wednesday 02 July 2008, Jonah H. Harris a =E9crit=A0:
> On Tue, Jul 1, 2008 at 8:18 PM, Jeffrey Baker <jwbaker@gmail.com> wrote:
> > Basically the ioDrive is smoking the RAID.  The only real problem with
> > this benchmark is that the machine became CPU-limited rather quickly.
>
> That's traditionally the problem with everything being in memory.
> Unless the database algorithms are designed to exploit L1/L2 cache and
> RAM, which is not the case for a disk-based DBMS, you generally lose
> some concurrency due to the additional CPU overhead of playing only
> with memory.  This is generally acceptable if you're going to trade
> off higher concurrency for faster service times.  And, it isn't only
> evidenced in single systems where a disk-based DBMS is 100% cached,
> but also in most shared-memory clustering architectures.

My experience is that using an IRAM for replication (on the slave) is very=
=20
good. I am unfortunely unable to provide any numbers or benchs :/ (I'll try=
=20
to get some but it won't be easy)
=20
I would probably use some flash/memory disk when Postgresql get the warm=20
stand-by at transaction level (and is up for readonly query)...

>
> In most cases, when you're waiting on disk I/O, you can generally
> support higher concurrency because the OS can utilize the CPU's free
> cycles (during the wait) to handle other users.  In short, sometimes,
> disk I/O is a good thing; it just depends on what you need.
>
> --
> Jonah H. Harris, Sr. Software Architect | phone: 732.331.1324
> EnterpriseDB Corporation | fax: 732.331.1301
> 499 Thornall Street, 2nd Floor | jonah.harris@enterprisedb.com
> Edison, NJ 08837 | http://www.enterprisedb.com/


=2D-=20
C=E9dric Villemain
Administrateur de Base de Donn=E9es
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org

--nextPart3318876.HmZrABPE6N
Content-Type: application/pgp-signature; name=signature.asc 
Content-Description: This is a digitally signed message part.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iEYEABECAAYFAkhrhEcACgkQo/dppWjpEvxevACg6Ly7733BMR7Hmk6gQmX4Bqan
FO4AoMp6na4o7ba/xxZgAA0rdEvqLx9A
=GN54
-----END PGP SIGNATURE-----

--nextPart3318876.HmZrABPE6N--