Re: Anyone for SSDs?

Поиск
Список
Период
Сортировка
От Josh Berkus
Тема Re: Anyone for SSDs?
Дата
Msg-id 4D02B2D1.3000900@agliodbs.com
обсуждение исходный текст
Ответ на Re: Anyone for SSDs?  (Daniel Loureiro <loureirorg@gmail.com>)
Ответы Re: Anyone for SSDs?  ("Joshua D. Drake" <jd@commandprompt.com>)
Re: Anyone for SSDs?  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
> 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.

You can believe whatever you want, that doesn't make it true.

Unless you have some kind of hard data that SSD data access is somehow
*qualitatively* different from SAS data access, then you're just
engaging in idle water-cooler speculation.

Plenty of vendors launched products based on the supposed
"revolutionary" nature of SSDs when they first came out.  All have
failed.  SSDs are just faster disks, that's all.  Their ratio of
random-access to sequential might be less than 4.0, but it's not 1.0.

Heck, even RAM isn't 1.0.  I'm also involved with the Redis project,
which is an in-memory database.  Even for a pure-RAM database, it turns
out that just using linked lists and 100% random access is slower than
accessing page images.

I use SSDs for many PostgreSQL instances.  They work great.  No changes
to PostgreSQL were required other than adjusting random_page_cost down
to 2.0 (this number could use exhaustive testing, but seems to work
pretty well right now).

--                                  -- Josh Berkus                                    PostgreSQL Experts Inc.
                        http://www.pgexperts.com
 


В списке pgsql-hackers по дате отправления:

Предыдущее
От: Tom Lane
Дата:
Сообщение: Re: ALTER EXTENSION ... UPGRADE;
Следующее
От: Andrew Dunstan
Дата:
Сообщение: Re: create tablespace fails silently, or succeeds improperly