Skip site navigation (1) Skip section navigation (2)

Re: SSD + RAID

From: Matthew Wakeling <matthew(at)flymine(dot)org>
To: Greg Smith <greg(at)2ndquadrant(dot)com>
Cc: Scott Carey <scott(at)richrelevance(dot)com>, Craig Ringer <craig(at)postnewspapers(dot)com(dot)au>, Laszlo Nagy <gandalf(at)shopzeus(dot)com>, Ivan Voras <ivoras(at)freebsd(dot)org>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: SSD + RAID
Date: 2009-11-20 11:54:58
Message-ID: alpine.DEB.2.00.0911201145190.684@aragorn.flymine.org (view raw or flat)
Thread:
Lists: pgsql-performance
On Thu, 19 Nov 2009, Greg Smith wrote:
> This is why turning the cache off can tank performance so badly--you're going 
> to be writing a whole 128K block no matter what if it's force to disk without 
> caching, even if it's just to write a 8K page to it.

Theoretically, this does not need to be the case. Now, I don't know what 
the Intel drives actually do, but remember that for flash, it is the 
*erase* cycle that has to be done in large blocks. Writing itself can be 
done in small blocks, to previously erased sites.

The technology for combining small writes into sequential writes has been 
around for 17 years or so in 
http://portal.acm.org/citation.cfm?id=146943&dl= so there really isn't any 
excuse for modern flash drives not giving really fast small writes.

Matthew

-- 
 for a in past present future; do
   for b in clients employers associates relatives neighbours pets; do
   echo "The opinions here in no way reflect the opinions of my $a $b."
 done; done

In response to

pgsql-performance by date

Next:From: Greg SmithDate: 2009-11-20 11:56:41
Subject: Re: Postgres query completion status?
Previous:From: Guillaume CottenceauDate: 2009-11-20 11:17:07
Subject: Re: Strange performance degradation

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group