Хрен
MasterZiv
В любой операционной системе создавать бесконечное число потоков
невозможно, и бессмысленно с точки зрения СУБД -- у неё все равно
5-20 процессоров только есть, больше потоков создавать бессмысленно --
это одна накладуха (в ОС). Лучше иметь 5-20 потоков и брать их
из пула и выполнять в них запросы, передавая им структуру контекста
выполнения серверного процесса. Последнюю структуру надо иметь
в любом случае, так зачем тогда 2000 потоков ?


Вот то что вы привели - это модель mysql 6. А pgsql этого не делает.

Пока глупые пользователь pgsql вовсю используют пул соединений PgBouncer , написанный какими-то хренами с бугра из ....
Модератор: лексика кульных хацкеров здесь не приветствуется, вплоть до их забанивания

zMakc
-В PostgreSQL мощнее триггеры и хранимые.
ИМХО реализовывать более менее серьезную логику на триггерах это извращение (хороший объектный код на C# или PHP гораздо проще поддерживать).

Когда в MySQL не было транзакций, их предлагалось реализовывать в приложении.
Когда в MySQL не было внешних ключей, в документации была глава, что "внешние ключи --- плохо".
Что-то мне подсказывает, что когда в MySQL наконец реализуют нормальную поддержку хранимых процедур и триггеров, то и хранение логики в базе ВНЕЗАПНО перестанет быть извращением.

И, кстати, в PostgreSQL можно писать триггеры и процедуры хоть на PHP .

zMakc
-Возможность использования разных типов таблиц в MySQL в некоторых случаях дает значительное превосходство

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

Как там, в MySQL уже можно использовать полнотекстовые индексы одновременно с транзакциями?

zMakc
-Как мне показалось с репликацией в MySQL дела обстоят лучше.

В том плане, что она там встроенная, one size fits all? А сколько решений для репликации в PostgreSQL рассматривалось, и какие именно?

::в сторону::
Что интересно, обычно одни и те же люди в одном и том же посте умудряются хвалить MySQL за множество табличных движков и утверждать, что множество различных решений для репликации в PostgreSQL --- плохо.

zMakc
Распространенность, количество специалистов, c MySQL ситуация лучше.

Распространённость, количество "специалистов", с Windows ситуация лучше. Почему-то на это очевидное сравнение пользователи MySQL очень обижаются.

Ну и забыли про главное достоинство PostgreSQL щас --- его не купил Оракл, и поэтому больше шансов на дальнейшее развитие, бгыгыгы.

zMakcSad Spirit,
авторВНЕЗАПНО перестанет Не перестанет. Одно дело базовые вещи, другое логика.

А где конкретно граница между базовыми вещами и логикой? Реализация ограничений на данные при помощи внешних ключей ещё хорошо, а при помощи триггеров --- уже плохо? Историю изменений записи тоже будем на похапэ реализовывать, чтобы потом концов не найти, когда кто-нибудь через консоль влезет?

Или напишем дерево по методу Nested Sets, а потом оно ВНЕЗАПНО развалится, ибо руками поправили .

А кстати об ограничениях, а MySQL уже CHECK понимать начал?

zMakc
авторпроцедуры хоть на PHP. Опять громкие заявления... На сайте указано что последний релиз 10/15/ 2007 (наверное поддержку версии 5.3 вот-вот сделают :) ) и судя по всему проект бете, это не для серьезного применения.

Ну да, не особо задался pl/php, ибо абсолютное большинство похапистов "знают" MySQL и неспособны выучить что-либо ещё, а без пользователей и смысла развивать нету. Но зато есть вполне стабильные pl/perl , pl/python , pl/tcl .

Есть и куча менее стабильных вещей , включая pl/java.

А на скольких языках можно писать процедуры для MySQL?..

zMakc
авторЧто интересно, обычно одни и те же люди в одном и том же посте умудряются хвалить MySQL за множество табличных движков... Потому что эти табличные движки идут в составе изначально. Это разные вещи.

То есть наличие табличных движков, которые не идут в составе изначально --- это плохо? Так и запишем.


zMakc
авторMySQL очень обижаются
Ничего обидного в этом нет (тем более Windows хороший продукт). Адекватных специалистов как ни крути в разы больше.

Адекватным можно быть только по отношению к чему либо. Поэтому тут не поспоришь: специалистов по MySQL, адекватных используемому продукту , действительно в разы больше.

zMakc
авторего не купил Оракл Ларри Элисон заявил что денег на разработку MySQL будут тратить больше чем Sun, не думаю что он бросает слова на ветер. Гробить MySQL им не выгодно, наоборот.
Ну да, только разработчики-то уже разбежались как тараканы. Какую из 50 новых несовместимых веток MySQL его пользователи планируют ставить через год-два? Ну и пока Ларри "заявляет", PostgreSQL развивается.

ХренSad Spirit
zMakc
-Как мне показалось с репликацией в MySQL дела обстоят лучше.

В том плане, что она там встроенная, one size fits all? А сколько решений для репликации в PostgreSQL рассматривалось, и какие именно?


А какие рабочие решения по репликации для pg предложили бы Вы?
А почемы Вы отвечаете вопросом на вопрос?

Я, пожалуй, подожду давать советы космического масштаба, etc. Пусть сначала автор расскажет, для какой задачи ему потребовалась репликация, какие решения он рассматривал, и по каким критериям ему "показалось".

Хрен
Ну этого добра и у нас есть.

http://forge.mysql.com/wiki/MySQL_Proxy

Тут тебе и пул коннекций, и переписывание запросов, и failover и load balancing. И разрабатывается в Сане.

???
Это скорее аналог pl/proxy , чем обычный пул соединений.