Гугловый аккаунт у меня есть, но этого оказывается мало:


Давно заметил - отечественные разработчики, даже опенсорс, зачастую страдают неизлечимой паранойей Так что спасибо за информацию, что ничего хорошего не планируют. Нафига тогда вообще конференция? Или по итогам конференции оказалось, что поддержка xml и полнотекстовый поиск это еще не все, что нужно от современной СУБД?..

Спасибо, хотя мы могли бы и в формате рассылки почитать.

Я бы пожалуй добавил к перечисленным вопросам еще парочку - о поддержке in-memory баз и таблиц (без журнала транзакций) и репликации между disk-based и in-memory таблицами, в т.ч. возможность при останове постгреса сбрасывать in-memory таблицы и базы на диск, а при запуске - считывать с диска (как на локальном постгресе, так и на удаленном).

Не уверен, что это кому-то интересно именно в постгресе - традиционно задача решается с помощью различных встраиваемых СУБД.
Сам я очень хотел бы увидеть в постгресе возможность подключать различные движки для хранения данных, как сейчас это сделано с процедурными языками, - тогда репликация и работа in-memory перестанет быть проблемой. Например, создал таблицу in-memory на движке mnesia, а этот движок умеет распределенную работу. Создал таблицу на движке эскулайт - можно сделать реплику нужных данных и отправить прямо в браузер (мозилла умеет с эскулайт работать). Конечно, работа планировщика постгреса станет нетривиальной, поскольку придется взаимодействовать с планировщиками подключенных движков, но это окупится неограниченным масштабированием полученной системы.

Andrey Daeron
Думаю планировщик станет настолько нетривиальным, что Ваши жалобы на нестабильность/непредсказуемость плана выполнения покажутся десткой забавой )))

Если ограничиться возможностью выборки только из таблиц одного типа, то можно просто передавать запрос планировщику соответствующего движка. Связывать разные типы таблиц можно на уровне функций на том или ином языке, благо их поддерживается множество. А использование стохастических методов в движке СУБД имхо тупиковый путь. Но про планировщик я ничего не говорил, поскольку подавляющее большинство проектов не нуждаются в мощном планировщике (уж если мускуль справляется, то и текущего планировщика постгреса с избытком хватит). Сейчас планировщик постгреса не умеет эффективно работать с результатами выполнения функций (те запросы, что я приводил, активно используют различные функции на pltcl), но это спорный вопрос, нужна ли такая функциональность в принципе. Возможно, более адекватным решением стало бы встраивание постгреса в систему анализа, но постгрес такую возможность не поддерживает.

А самое пожалуй важное - увидеть план развития постгреса на ближайшие 5 лет. Для корпоративного ПО такой план просто необходим.

MasterZiv
Поглядите на MySQL, там всё равно только два движка используются,
и то - не одновременно (одни - один, MyISAM, другие - другой, Inno)


На мускуль глядеть не хочу, плохо делается... И движки там отнюдь не реляционные. А я говорил о возможности использовать в постгресе в т.ч. и реляционные движки со своим парсером и планировщиком.

К чему это приведет - сложно сказать. А вот отсутствие плана разработки точно ни к чему хорошему не привело и не приведет. Имхо движок постгреса и так в свалку превращают поддержкой разных xml и fts, которые были модулями и должны были ими остаться. Жизнеспособность же модулей из contrib вызывает сомнения, хотя в какой-то версии постгреса когда-то они работали (непонятно, правда, насколько успешно).

iz MBGИмхо движок постгреса и так в свалку превращают поддержкой разных xml и fts, которые были модулями и должны были ими остаться.

Совершенно неверное мнение. Поглядите на то, как сейчас Том Лейн противится включению PL/Proxy в ядро и поймете, что свалкой движок, который так принципиально охраняется высококлассными разработчиками, назвать ну уж никак язык не поворачивается. Главное, все, что включается в ядро, включается туда не из каких-нибудь маркетинговых соображений, а во благо пользователей. Мне лично и огромному количеству проектов, в которых я участвую, от ФТС в ядре только польза. И я считаю, что самые популярные контрибы должны плавно мигрировать в ядро, чтобы многочисленные пользователи не мучились с их установкой. Да, еще не забывайте, что многим фичам вы можете сделать --disable.

Postgres 8.1 - 2.8 Mb, 8.3 - 3.6 Mb. Для сравнения, кстати, initrd.img-2.6.24-1-686 "весит" 5.8 Mb. Это уже слишком большой объем кода. А ведь стоит еще учесть те дополнительные библиотеки, которые вызываются модулями или функциями.

Если вам нужен полнотекстовый поиск, вы могли собрать постгрес с его поддержкой. А мне вот этот поиск не нужен, но собрать постгрес без его поддержки я не могу - судя по объему патчей, принятых для интеграции fts, был перелопачен чуть ли не весь код.

Открытое ПО тем и ценно, что дает почти полный контроль (конечно, время ограничено, будь то время на разработку или изучение документации и исходников). Например, понадобится мне реализовать криптацию данных на уровне страниц данных с помощью российских криптоалгоритмов (это одно из требований для некоторых видов сертификации продукта) - я не смогу это сделать в постгресе. В эскулайте такая работа займет у меня несколько недель времени, но она осуществима. Если же такая задача встанет для проекта на постгресе - это катастрофа, поскольку потребует замены СУБД. Полнотекстовый поиск, думаю, мне понадобится через несколько месяцев - но я предпочту сделать стеммер для поддержки морфологии русского языка для эскулайт, пользуясь словарем и affix-файлом для русского языка из ispell (в постгресе есть и другие возможности в моделе полнотекстового поиска, но это как пример). Это займет одну-две недели, но на фоне нескольких лет поддержки проекта это совсем немного. Зато я получу модуль, который можно модифицировать, не переделывая саму СУБД, скорость работы которого можно оценить независимо от СУБД и т.п. И так думаю не только я - PostGIS уже имеет аналог - spatialite для sqlite, есть полнотекстовый поиск fts3 для sqlite и целая куча более мелких модулей (как пример - модуль поддержки операций над ipv4 адресами я написал и протестировал за один день, собрал эскулайт с ним и все это не потребовало особенных усилий). Поиск - это хорошо, но без поддержки collation уже начинаются проблемы, а уж для добавления собственного стеммера пересобирать постгрес...

Если вы посмотрите внимательно, то расширений к постгресу совсем немного для проекта, развивающегося более двух десятилетий. А те расширения, что есть, зачастую недоделаны и лежат в контрибах. В частности, потому, что требуют модификации постгреса для своей быстрой и/или стабильной работы. Получается "черный ящик" вместо расширяемого проекта. Вот вам результаты включения избыточного кода в ядро системы. Я бы с удовольствием сделал расширения, необходимые мне в постгресе, но черта с два их удастся нормально "прицепить" в виде сторонних модулей - тот же cube и пр. требуют поддержки в ядре, иначе овчинка выделки не стоит. Попытки менять ядро системы тоже бывает проваливаются - вспомним pgCluster.

С точки зрения пользователя все может не так заметно, но при отсутствии разработчиков чем вы собираетесь пользоваться?..

Andrey Daeron MBG
А самое пожалуй важное - увидеть план развития постгреса на ближайшие 5 лет. Для корпоративного ПО такой план просто необходим.
Т.е. Вы всерьёз собираетесь строить свои планы опираясь на планы развития свободного продукта?
Я не к тому, что постгрес будет/небудет развиваться и достоин/недостоин быть СУБД в корпоративе, но доже роадмепы Мелкомягких, Ораклов и т.д. весьма плавающи.

Имея план развития, можно связаться с разработчиком интересующего меня модуля и узнать о текущем состоянии дел, протестировать или помочь в разработке. Сейчас же каждый разработчик сам по себе и невесть сколько времени пройдет до реализации, да еще потом непонятно, будет ли код включен в апстрим.