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/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
