Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

en at gross capacity. Robert Original message >Date: Tue, 17 Aug 2010 23:37:26 -0700 (PDT) >From: pgsql-performance-ow...@postgresql.org (on behalf of da...@lang.hm) >Subject: Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD >vs desktop HDD >To: Brad N

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

On Thu, 12 Aug 2010, Brad Nicholson wrote: On 10-08-12 03:22 AM, Arjen van der Meijden wrote: On 12-8-2010 2:53 gnuo...@rcn.com wrote: - The value of SSD in the database world is not as A Faster HDD(tm). Never was, despite the naive' who assert otherwise. The value of SSD is to enable BCNF da

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

As a postscript to these tests.. I just tried the 500GB Monentus XT hybrid SSD/HDD drive. I had this fantasy that it would at least do better than the 7200 rpm desktop drive. Oh lord, my gut was wrong. The performance was inconsistent and never over 2/3rds the performance of the slowest desktop d

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

On 13-8-2010 1:40 Scott Carey wrote: Agreed. There is a HUGE gap between "ooh ssd's are fast, look!" and engineering a solution that uses them properly with all their strengths and faults. And as 'gnuoytr' points out, there is a big difference between an Intel SSD and say, this thing: http://ww

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

On Aug 11, 2010, at 9:30 PM, Greg Smith wrote: > Scott Carey wrote: >> What is the likelihood that your RAID card fails, or that the battery that >> reported 'good health' only lasts 5 minutes and you lose data before power >> is restored? What is the likelihood of human error? >> > > These

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

On 10-08-12 03:22 AM, Arjen van der Meijden wrote: On 12-8-2010 2:53 gnuo...@rcn.com wrote: - The value of SSD in the database world is not as A Faster HDD(tm). Never was, despite the naive' who assert otherwise. The value of SSD is to enable BCNF datastores. Period. If you're not going to d

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

On 12-8-2010 2:53 gnuo...@rcn.com wrote: - The value of SSD in the database world is not as A Faster HDD(tm). Never was, despite the naive' who assert otherwise. The value of SSD is to enable BCNF datastores. Period. If you're not going to do that, don't bother. Silicon storage will never rea

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

gnuo...@rcn.com wrote: Sufficiently bulletproof flash SSD exist and have for years, but their names are not well known (no one on this thread has named any) The models perceived as bulletproof are the really dangerous ones to deploy. First, people let their guard down and stop being as paran

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

Scott Carey wrote: What is the likelihood that your RAID card fails, or that the battery that reported 'good health' only lasts 5 minutes and you lose data before power is restored? What is the likelihood of human error? These are all things that happen sometimes, sure. The problem with

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

A number of amusing aspects to this discussion. - I've carried out similar tests using the Intel X-25M with both PG and DB2 (both on linux). While it is a simple matter to build parallel databases on DB2, on HDD and SSD, with buffers and tablespaces and logging and on and on set to recreate as

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

Scott Carey wrote: > > On Aug 10, 2010, at 11:38 AM, Karl Denninger wrote: > > . >> >> Most people who will do this won't reload it after a crash. They'll >> "inspect" the database and say "ok", and put it back online. Bad >> Karma will ensue in the future. > > Anyone going with something unc

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

On Aug 10, 2010, at 11:38 AM, Karl Denninger wrote: Scott Marlowe wrote: On Tue, Aug 10, 2010 at 12:13 PM, Karl Denninger wrote: ANY disk that says "write is complete" when it really is not is entirely unsuitable for ANY real database use. It is simply a matter of

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

On Aug 10, 2010, at 11:28 AM, Greg Smith wrote: > Brad Nicholson wrote: >> What about putting indexes on them? If the drive fails and drops >> writes on those, they could be rebuilt - assuming your system can >> function without the index(es) temporarily. > > Dumping indexes on SSD is one of

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

On Aug 10, 2010, at 9:21 AM, Greg Smith wrote: > Scott Carey wrote: >> Also, the amount of data at risk in a power loss varies between >> drives. For Intel's drives, its a small chunk of data ( < 256K). For >> some other drives, the cache can be over 30MB of outstanding writes. >> For some wo

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

On Tue, Aug 10, 2010 at 2:00 PM, Christopher Browne wrote: > On Tue, Aug 10, 2010 at 3:52 PM, Scott Marlowe > wrote: >> My point being, no matter how terrible an idea a certain storage media >> is, there's always a use case for it.  Even if it's very narrow. > > The trouble is, if extra subscrib

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

On Tue, Aug 10, 2010 at 3:52 PM, Scott Marlowe wrote: > My point being, no matter how terrible an idea a certain storage media > is, there's always a use case for it.  Even if it's very narrow. The trouble is, if extra subscribers induce load on the "master," which they presumably will, then that

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

On Tue, Aug 10, 2010 at 12:38 PM, Karl Denninger wrote: > Scott Marlowe wrote: > > On Tue, Aug 10, 2010 at 12:13 PM, Karl Denninger wrote: > > > ANY disk that says "write is complete" when it really is not is entirely > unsuitable for ANY real database use.  It is simply a matter of time > > > Wh

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

On 8/10/2010 3:28 PM, Karl Denninger wrote: Brad Nicholson wrote: On 8/10/2010 2:38 PM, Karl Denninger wrote: Scott Marlowe wrote: On Tue, Aug 10, 2010 at 12:13 PM, Karl Denninger wrote: ANY disk that says "write is complete" when it really is not is entirely unsuitable for ANY real dat

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

Brad Nicholson wrote: > On 8/10/2010 2:38 PM, Karl Denninger wrote: >> Scott Marlowe wrote: >>> On Tue, Aug 10, 2010 at 12:13 PM, Karl Denninger wrote: >>> ANY disk that says "write is complete" when it really is not is entirely unsuitable for ANY real database use. It is simply a ma

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

On 8/10/2010 2:38 PM, Karl Denninger wrote: Scott Marlowe wrote: On Tue, Aug 10, 2010 at 12:13 PM, Karl Denninger wrote: ANY disk that says "write is complete" when it really is not is entirely unsuitable for ANY real database use. It is simply a matter of time What about read on

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

On 8/10/2010 2:28 PM, Greg Smith wrote: Brad Nicholson wrote: What about putting indexes on them? If the drive fails and drops writes on those, they could be rebuilt - assuming your system can function without the index(es) temporarily. Dumping indexes on SSD is one of the better uses for t

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

Scott Marlowe wrote: > On Tue, Aug 10, 2010 at 12:13 PM, Karl Denninger wrote: > >> ANY disk that says "write is complete" when it really is not is entirely >> unsuitable for ANY real database use. It is simply a matter of time >> > > What about read only slaves where there's a master wit

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

Brad Nicholson wrote: What about putting indexes on them? If the drive fails and drops writes on those, they could be rebuilt - assuming your system can function without the index(es) temporarily. Dumping indexes on SSD is one of the better uses for them, presuming you can survive what is li

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

On Tue, Aug 10, 2010 at 12:13 PM, Karl Denninger wrote: > ANY disk that says "write is complete" when it really is not is entirely > unsuitable for ANY real database use.  It is simply a matter of time What about read only slaves where there's a master with 100+spinning hard drives "getting it r

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

Brad Nicholson wrote: > On 8/10/2010 12:21 PM, Greg Smith wrote: >> Scott Carey wrote: >>> Also, the amount of data at risk in a power loss varies between >>> drives. For Intel's drives, its a small chunk of data ( < 256K). >>> For some other drives, the cache can be over 30MB of outstanding >>>

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

On 8/10/2010 12:21 PM, Greg Smith wrote: Scott Carey wrote: Also, the amount of data at risk in a power loss varies between drives. For Intel's drives, its a small chunk of data ( < 256K). For some other drives, the cache can be over 30MB of outstanding writes. For some workloads this is ac

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

Jeff Davis wrote: Depending on which 256K you lose, you might as well lose your entire database. Let's be nice and assume that you only lose one 8K block because of the SSD write cache; that's not so bad, right? Guess what--you could easily be the next lucky person who discovers the block

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

Scott Carey wrote: Also, the amount of data at risk in a power loss varies between drives. For Intel's drives, its a small chunk of data ( < 256K). For some other drives, the cache can be over 30MB of outstanding writes. For some workloads this is acceptable No, it isn't ever acceptable. Y

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

On Mon, 2010-08-09 at 09:49 -0700, Scott Carey wrote: > Also, the amount of data at risk in a power loss varies between > drives. For Intel's drives, its a small chunk of data ( < 256K). For > some other drives, the cache can be over 30MB of outstanding writes. > For some workloads this is accept

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

On Aug 7, 2010, at 11:49 PM, Michael March wrote: SSD's actually vary quite a bit with typical postgres benchmark workloads. You mean various SSDs from different vendors? Or are you saying the same SSD model might vary in performance from drive to drive? Model to model (more specifically, con

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

Michael March wrote: If anyone is interested I just completed a series of benchmarks of stock Postgresql running on a normal HDD vs a SSD. If you don't want to read the post, the summary is that SSDs are 5 to 7 times faster than a 7200RPM HDD drive under a pgbench load. http://it-blog.5amso

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

On Sun, Aug 8, 2010 at 12:49 AM, Michael March wrote: > >> SSD's actually vary quite a bit with typical postgres benchmark workloads. > > You mean various SSDs from different vendors? Or are you saying the same SSD > model might vary in performance from drive to drive? > >> >>  Many of them also d

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

> > On Sat, Aug 7, 2010 at 5:47 PM, Michael March wrote: > > If anyone is interested I just completed a series of benchmarks of stock > > Postgresql running on a normal HDD vs a SSD. > > If you don't want to read the post, the summary is that SSDs are 5 to 7 > > times faster than a 7200RPM HDD dri

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

On Sat, Aug 7, 2010 at 5:47 PM, Michael March wrote: > If anyone is interested I just completed a series of benchmarks of stock > Postgresql running on a normal HDD vs a SSD. > If you don't want to read the post, the summary is that SSDs are 5 to 7 > times faster than a 7200RPM HDD drive under a p

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

> SSD's actually vary quite a bit with typical postgres benchmark workloads. > You mean various SSDs from different vendors? Or are you saying the same SSD model might vary in performance from drive to drive? > Many of them also do not guarantee data that has been sync'd will not be > lost if p

Re: [PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

SSD's actually vary quite a bit with typical postgres benchmark workloads. Many of them also do not guarantee data that has been sync'd will not be lost if power fails (most hard drives with a sane OS and file system do). On Aug 7, 2010, at 4:47 PM, Michael March wrote: If anyone is intereste

[PERFORM] Completely un-tuned Postgresql benchmark results: SSD vs desktop HDD

If anyone is interested I just completed a series of benchmarks of stock Postgresql running on a normal HDD vs a SSD. If you don't want to read the post, the summary is that SSDs are 5 to 7 times faster than a 7200RPM HDD drive under a pgbench load. http://it-blog.5amsolutions.com/2010/08/perform