> по моему ему уже конкуренции среди opensource СУБД нет.

Среди opensource - да, и уже давно.

Вот Oracle по-прежнему смотрит на всех конкурентов, кроме DB/2, как на говно.

>Вот Oracle по-прежнему смотрит на всех конкурентов, кроме DB/2, как на говно.

Поэтому их капец не за горами.

круто

>Не помню. Может быть.

Стандартная конфигурация постгреса, которая почти везде по-дефолту, рассчитана чуть ли не на запуск на мобильниках.

Его всегда надо перенастраивать перед использованием, тогда производительность вполне хороша.

Было бы интересно послушать сравнительный анализ этой версии PostgreSQL с Oracle. DBA на ЛОРе есть?

Сравнивать пока нечего. Нет матвью (скоро будет), нет партиционирования (тоже скоро должно появиться), нет штатных инструментов для резервирования типа rman (самое лучшее это pg-rman), нет флешбека (просмотр удалённых записей, хотя архитектурно в PG сделать не трудно), нельзя делать полные отладочные трейсы для поиска боттелнеков и исключительных ситуаций (есть systemtap, но это скорее для гиков инструмент чем для DBAшника. Да, оптимизация в PG ещё долго будет шаманством), нет никаких фич с распаррареливанием сложных запросов на несколько ядер(процессов), нет аналога RAC (это совсем не скоро будет даже в планах), нет понятия shared server (аналог делается через коннекшн пулы. В оракл db вообще более богатая работа с сетью на уровне самой библиотеки клиента), триггеры пока можно вешать только на события DML.

С другой стороны, PG открытый продукт без энтерпрайза (и явы) головного мозга, не требует лишних ресурсов на поддержку древних пакетов, постепенно допиливают полезные фичи. Есть свои уникальные плюшки - GiST/GIN + сейчас где-то разрабатывают аналогичную инфраструктуру для векторных типов. Хорошая возможность для реализации пользовательских типов данных, достаточно большая база расширений (новые сложные типы + индексы). «Синтаксис» более юзер френдли, но в общем похож на оракловый.

Полноценная изоляция сериализуемых (serializable) транзакций. В старых версиях могли происходить некоторые аномалии, которые теперь устранены. Старый алгоритм изоляции ныне соответствует уровню «Repeatable read».

а можно тут подробнее ? что за аномалии присутствовали и точно ли serializable или все таки аля оракловое сириализабле ?

Когда-то мерял производительность MySQL4, MySQL5 и PG8 на одной и той же железяке на простеньких запросах INSERT/SELECT/UPDATE/DELETE. >> Тупо, «кто быстрее выполнит 100000 запросов».
Стабильно MySQL4 был самым быстрым. А постгре - самым медленным, только на селектах относительно приближался к MySQL5. :)

А текстовый файлик будет ещё быстрее! И чё все на этих тормозных СУБД сидят, когда есть такие быстрые текстовые файлики?

З.Ы. А если померять мыскуль и слона по запросу типа

SELECT 
... 
FROM table1 t1
INNER JOIN table2 t2 ON t2.f1=t1.f1
INNER JOIN table3 t3 ON t3.f1=t2.f1
INNER JOIN table4 t4 ON t4.f1=t3.f1
INNER JOIN table5 t5 ON t5.f1=t4.f1

Насколько мыскуль тут окажется в анусе?

Вот тут всё подробно описано, с примерами

Стабильно MySQL4 был самым быстрым. А постгре - самым медленным, только на селектах относительно приближался к MySQL5. :)

Сравнивал какие-то синтетические задачи на дефолтовых настройках? Иди на фороникс, запили там статью. Там такие «„тестировщики“» востребованы.

Оно ж дико медленно будет, ведь сетевые задержки есть.

На инфинибенде или 10G нормально.

И что характерно в новостях НИЧЕГО не сказано о ПОЛИТИКАХ и СОЛЮЩЕНАХ.

Самая здравая БД, хоть о FB скажу, что не далеко отстоят....

Ты еще select a from (select from z) as x left join on y (x.f=y.a) сравни. Они как и MS SQL это не в курсе... Темные люди.

select a from (select from z)

Для таких случаев лучше WITH. Во всяком случае планы с WITH у меня были лучше...

А MSSQL, как водится, не нужен.

> Добавлена поддержка SELinux и команды SECURITY LABEL.

теперь торт

> Когда-то мерял производительность MySQL4, MySQL5 и PG8 на одной и той же железяке на простеньких запросах INSERT/SELECT/UPDATE/DELETE. Тупо, «кто быстрее выполнит 100000 запросов». Стабильно MySQL4 был самым быстрым. А постгре - самым медленным, только на селектах относительно приближался к MySQL5. :)

Это типа откровение такое?

Постгрес и не позиционируется как самая быстрая СУБД. У него акцент на фичах, если что. :)

>Нетъ, ничего подобного. 1С совершенно нипричём.

Ясно, я перепутал значит с этим:

индексная поддержка операции LIKE и SIMILAR TO (в PostgreSQL это невозможно для не-ASCII символов),

>> Видели когда-нибудь потроха хоть одной не игрушечной реализации?

newlisp достаточно неигрушечна?

Штучка эта вполне интересна. Но можете назвать несколько успешных продуков, созданных с помощью newlisp? Мне что-то ничего в голову не приходит.

ИМХО единственный неигрушечный лисп - Common LISP. И хотя стандарт этот приличным и вменяемым назвать язык не хочет поворачиваться, на нем хоть писали реальный софт.

индексная поддержка операции LIKE и SIMILAR TO

Кстати, это было (да и чейчас) не особо нужно, в связи с наличием отличнейшего fts, и того же pg_trgm, который сам по себе является мегасуперкиллерфичей для поиска по строкам («поиск с опечатками» - это именно оно).

а репликации какого типа поддерживаются ? скажем мастер - мастер поддерживаются ?

> Когда-то мерял производительность MySQL4, MySQL5 и PG8 на одной и той же железяке на простеньких запросах INSERT/SELECT/UPDATE/DELETE. Тупо, «кто быстрее выполнит 100000 запросов».

Стабильно MySQL4 был самым быстрым. А постгре - самым медленным, только на селектах относительно приближался к MySQL5. :)

У постгреса как минимум fsync по дефолту включен. А у mysql? Плюс что было выбрано в MySQL, MyISAM или таки InnoDB?

Глядишь и машину времени такими темпами реализуют :)

MyISAM

InnoDB оно, знаете ли, такое специфическое...

Троекратное УРА

ну так попробуй все эти тесты на сложных запросах , с десятком таблиц и прикинь про кактус...

Префиксный поиск работает по индексу в любой локали

Конечно нет

ну ну, выбирали этим летом субд для переноса проекта с mssql: fb,mysql(5.1 innodb),pg 8.x. первых 2 не догнали и mssql, третьего не смог догнать сам mssql. oracle там излишне дорог и монструозен.

FFGJ

В версии 8.1, что была в n-том обновлении debian etch, ILIKE для русского языка ничего не находил (для UTF8 разумеется). Для СУБД это fatal error, хуже может быть только порча данных на диске.

>> В версии 8.1, что была в n-том обновлении debian etch, ILIKE для русского языка ничего не находил (для UTF8 разумеется). Для СУБД это fatal error, хуже может быть только порча данных на диске.

Это лечится путем установки локали при создании кластера командой initdb. Сейчас уже это делается на уровне баз данных. Недавно сам с этим сталкивался, так что не надо заливать.

> Синхронная репликация в распределённой БД.

а говорят, что никакой распределенной БД в постгресе нет; врут что ли?

>Добавлена поддержка SELinux и команды SECURITY LABEL.

не понял, они сделали разделение доступа к объектам базы на основе политик SELinux?

>а репликации какого типа поддерживаются ? скажем мастер - мастер поддерживаются ?

Это где-то тут.

Тупо, «кто быстрее выполнит 100000 запросов».

Не надо делать тупо. На тупых запросах мыскуль даже оракла обгонит. Но это ж ни о чём не говорит на самом деле.

>не понял, они сделали разделение доступа к объектам базы на основе политик SELinux?
Именно.

Постгрес и не позиционируется как самая быстрая СУБД. У него акцент на фичах, если что. :)

Был акцент на фичах. После 8.х версии у мыскуля не осталось особых преимуществ в скорости.

Кстати, это было (да и чейчас) не особо нужно, в связи с наличием отличнейшего fts

FTS — прикольная штука, но нам пришлось перейти всё-таки на sphinx, слишком уж он кардинально быстрее.

InnoDB оно, знаете ли, такое специфическое...

Какое? Позволяет таки полноценно поддерживать целостность базы? Обычным «мышкам без кактусов» это не нужно?

> Но можете назвать несколько успешных продуков, созданных с помощью newlisp?

нет. но ведь разговор не о том?

ИМХО единственный неигрушечный лисп - Common LISP

я думал, под неигрушечностью подразумевается не распространённость/элитность/..., а некий набор возможностей. до newlisp для встраивания в свой софт использовал tinyscheme, но его-то как-раз можно назвать игрушечным — есть неприятные моменты, не позволяющие использовать полноценно.

> FTS — прикольная штука, но нам пришлось перейти всё-таки на sphinx, слишком уж он кардинально быстрее.

Если данные редко меняются, то sphinx может быть неплохим решением.
В противном случае вообще не канает.

Если данные редко меняются, то sphinx может быть неплохим решением. В противном случае вообще не канает.

Если уж речь зашла про sphinx, то не спроста. Поиск с использованием FTS работал слишком долго для наших требований. Дальнейшей оптимизации с использованием только postgresql запросы не поддавались, сфинкс решил проблемы.

> Когда-то мерял производительность MySQL4, MySQL5 и PG8 на одной и той же железяке на простеньких запросах INSERT/SELECT/UPDATE/DELETE

Это известная штука - mysql (конкретно myisam) при небольшом размере индексов рвет на простых запросах SELECT/INSERT почти все остальные базы. Если транзакции не нужны и без сложных запросов можно обойтись, то зная эти тонкости умельцы собирают в нем терабайтные базы, и производительность там ограничена только скоростью файловой системы.

Вообще mysql - это БД для админов-хакеров, которые могут работать одновременно и на высоком и на низком уровне, потому что он прост, как пробка, и легко хакается. Отдельные файлы-таблицы позволяют прямо на живом сервере перетащить несколько файлов на другой раздел, а в каталоге базы сделать на них симлинки. Таким методом делались экзотические репликации - «реплицируемые» таблицы выносились на сетевой диск.

А если запросы сложные и с транзакциями, программеры требуют вынести логику запросов в процедуры на сервер БД, некогда читать DESCRIBE, думать об особенностях протокола и низкоуровневой работы с файлами, фрагментацией индексов или вручную следить за размерами таблиц, то postgresql должен рулить и педалить.

PS: это лор или не лор, где «велосипед», «не нужен», крики что гугль и фейсбук юзают mysql и ссылки на тесты, где посгрес рвут на мячики?

Кстати, это было (да и чейчас) не особо нужно, в связи с наличием отличнейшего fts, и того же pg_trgm, который сам по себе является мегасуперкиллерфичей для поиска по строкам («поиск с опечатками» - это именно оно).

pg_trgm это ужасный костыль. Нихрена он не ищет по подсрокам и не маскирует опечатки. Всего навсего делает видимсоть «fuzzy search»'а и не более.

Если данные редко меняются, то sphinx может быть неплохим решением. В противном случае вообще не канает.

в сфинксе есть RT индексы, некоторые задачи часто обновляемых данных можно решать с их помощью.

Вообще mysql - это БД для админов-хакеров, которые могут работать одновременно и на высоком и на низком уровне, потому что он прост, как пробка, и легко хакается.

ох лол... таки тройное деление на ноль.

> ох лол... таки тройное деление на ноль.

А для вас сюрприз, что все триггеры, процедуры, view и join-ы выливаются в банальные операции чтения и записи на файловой системе? Зря. Это сильно помогает в тонкой оптимизации. Скажем, зная, что одна из таблиц должна работать быстрее других, я могу вынести ее на отдельный диск, проверить, что он больше ничем не загружен, а файлы таблицы и индексов не фрагментированы. Понимая, в какие операции чтения/записи выливаются выполняемые запросы, я могу создать подходящий рейд с нужными параметрами. Если я знаю, что файл индексов - это дерево, понимаю, что за операцией «вставки в таблицу» стоит перестроение этого дерева, и знаю, как оно выполняется, то могу определить ограничения на структуру и размер таблиц и индексов под требуемые уровни производительности.

Вообще, знание того инструмента, которым вы пользуетесь, позволяет вам целенаправленно находить и решать проблемы, а не тупо тыкать разные параметры нагугленные на форумах, и приговаривать «чего ж оно так тупит». Mysql имеет меньше возможностей, но он прост, и изучить его, как инструмент, легко. Об этом и шла речь. Если вы готовы изучить свой инструмент и его ограничения не являются проблемой, то из mysql-я можно выжать куда большую производительность. Вроде как это известный факт же. :)

Не помню. Может быть.

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

http://postgresql.ru.net/pgtune/postgresql.html

> Нихрена он не ищет по подсрокам

Ищет, как раз с версии 9.1

> Вот Oracle по-прежнему смотрит на всех конкурентов, кроме DB/2, как на говно.

И на него тоже. Взять хотя бы блокировки DB2 (с возможностью эскалации) vs consistent read Oracle.

Ну и для 24/7 баз в DB2 просто бесит необходимость reorg даже после обычного добавления колонки.