Зл0й Yo!. Зл0й
По "функционалу" ему до коммерческих СУБД PG еще как до звезд. Пусть сначала перепишут ядро, ликвидируют необходимость в vacuum/garbage collector, сделают Write-ahead logging как в коммерческих СУБД и добьются стабильной работы и масштабируемости. Тогда и будет предмет для обсуждения. А пока обсуждать нечего.

а чем плох их WAL ?

Тем что надежность и производительность оставляют желать лучшего. И вообще хранить версии в страницах не надо, для этого логи есть.
Зл0й, ты не прав.
Слова по поводу надежности нужно обосновать, иначе (извини за ЛОРовский жаргон) это похоже на пердёж в луже.

Постгресс один из немногих, кто хранит версии на страницах данных (впрочем есть еще и Interbase).
Да, это немного сказывается на производительности.
Но зато никаких проблем с ролбэком :-) Не раз встречал предупреждения для и InnoDB, и для Oracle, что rollback обычно длиться в десять раз дольше, чем длилась отменённая транзакция :-)
А в PostgreSQL нет. Отменил и всё. И нет её.

И кроме того. Думаешь в OLTP выгоднее лезть за версией в лог? Вместо того, чтобы взять её здесь же, на странице?
В каждом случае по разному. Где-то лучше в лог лезть. А где-то не заморачиваться, и взять рядышком.

Ну а на добивание, полистай, посмотри как масштабируется PostgreSQL 8.2
Могу спорить, что принятая система версионности играет в такой линейной масштабируемости не посленюю роль :0)
Share Nothing - лучший друг масштабируемости :0)

http://www.whenpenguinsattack.com/2006/03/14/10-database-speed-tests/

PostgreSQL 8.1.2 всего в полтора раза хуже MySQL 5.0.18 в "однопользовательском" режиме.
За исключением INNER JOIN ;-)

Вообще конечно ужасный тест. В основном раскрывает SQLite :0)

Да он как раз таки SqlLite и пропгандировал. По крайней мере, набор тестов типичный для SqlLite

Кроме того SqlLite не однопользовательский - он позволяет одновременно многим процессам работать с одной базой.
Правда блокировка на запись для всего файла. Но для web это не является большой проблемой, да?
Ну а читать одновременно могут все. Так что SqlLite может занять свою нишу.

Пример: на вебхостинге с поддержкой PHP5x. Если чувствуешь, что начинается затык на общем SQL сервере, можешь
заюзать SqlLite, и никого не ждать :0)

Блин. Ну когда уже ValueHost перейдет на PHP 5 ?

Di_LIne
Ну да... И накой тогда каждый раз лазить в БД?

Это проще, чем настраивать офигенную систему кэширования, которая нужна потому, что к бд надо лезть по сети,
а у хостера ещё две сотни сайтов к тому же серваку обращаются.

А когда у тебя бд здесь же, шустрая и никому кроме тебя не нужная, то какая нафиг разница - кэшируешь ты в файлах,
или выбираешь из таблицы. Гемора существенно меньше. Согласен со мною?

Di_LIne
Нет. Ибо это опровергается элементарным ПРОСМОТРОМ производимых операций:
1. вариант - файло: - Апачь-файл-Апачь
2. вариант - БД: - Апачь-PHP(или другое)-SQL-сервер-PHP(или другое)-Апачь

Ну не совсем правильно:
1. вариант - файло: - Апачь-PHP(поискали файло)-файло-PHP(убедились, что файло - то что нам надо)-Apache

Ибо я говорю не про статичные страницы, а про кэш выбранного движка сайта, а движок на PHP(или другое).
А SQLite не сильно отличается по скорости от "файло".
Не буду дальше спорить: я тестов не делал, судя по всему, ты тоже. Поэтому это всё не больше, чем газификация лужи.

Di_LIneУточню схему: Апачь - Сам ищет файло на HDD - Вернул результ броузеру.
Схема сия априоре БЫСТРЕЕ, чем указанная Вами, по той причине, что PHP в данном случае - излишняя, програмная пройслойка.
Даже не упоминаю о наихудшем варианте, с точки зрения быстродействия, PHP-интерпритатор.

Подскажи CMS, которая свой кэш мимо себя пропускает, прямиком апачу? Буду очень рад открыть для себя что-то новое.

Нет, наверняка есть такие. Только я о них не знаю. А ты?

ОК, я умыт :-(