Re: Anyone for SSDs? - Mailing list pgsql-hackers

From Hannu Krosing
Subject Re: Anyone for SSDs?
Date
Msg-id 4D02BC05.2030406@2ndquadrant.com
Whole thread Raw
In response to Re: Anyone for SSDs?  (Daniel Loureiro <loureirorg@gmail.com>)
Responses Re: Anyone for SSDs?  (Daniel Loureiro <loureirorg@gmail.com>)
Re: Anyone for SSDs?  (Daniel Loureiro <daniel@termasa.com.br>)
List pgsql-hackers
On 10.12.2010 21:21, Daniel Loureiro wrote:
>
>> The fact that it's called md.c is a hangover from the '80s.  These days,
>> the logic that the Berkeley guys envisioned being at that code level
>> is generally in kernel device drivers.  md.c can drive anything that
>> behaves as a block device + filesystem, which is pretty much everything
>> of interest.
> I believe that PostgreSQL was been developed and optimized for
> sequential access. To get full advantage of SSDs its necessary to
> rewrite almost the whole project - there are so much code written with
> the sequential mechanism in mind.
Nope, as a matter of fact postgreSQL was developed as a university 
project with flexibility and extensibility among top goals.
Yes, "magnetic disk" is the only storage manager left in current code 
base, but the original design had more, most notably the WORM (Write 
Once Read Many) disks, one of the uses being for the old design of 
VACUUM which did not throw away deleted rows but moved them to WORM 
disks for historical queries. The WORM disks were the "next big thing in 
storage" a few tens of years ago.

And as  Josh Berkus notes in another replay, nowadays even RAM is not 
neutral to access patterns - pipeline stalls and cache flushes can have 
impact of several orders of magnitude on execution speeds.

----------------------
Hannu Krosing
PostgreSQL Infinite Scalability and High Availability
http://www.2ndquadrant.com/books/


pgsql-hackers by date:

Previous
From: Jeff Janes
Date:
Subject: Re: Anyone for SSDs?
Next
From: Josh Berkus
Date:
Subject: Re: would hw acceleration help postgres (databases in general) ?