LINUX.ORG.RU

PostgreSQL 9.2

 


1

2

Вышла новая версия СУБД PostgreSQL — 9.2.

Основные изменения в этой версии:

  • «Index Only Scans» — возможность выбирать данные прямо из индекса, если в индексе они есть. До этого СУБД использовала индекс только для поиска, непосредственно данные всегда выбирались из страниц данных. Данная функция работает только в случае если страница с искомыми данными не менялась с момента последней операции VACUUM.
  • Каскадная репликация — standby сервера теперь тоже могут отправлять журнал транзакций другим узлам.
  • Поддержка типа данных JSON для хранения неструктурированных документов.
  • Добавлены типы данных для диапазонов значений.
  • Серия различных оптимизаций производительности, в том числе:
    • улучшенная работа с блокировками на системах с 32-мя и более ядрами;
    • функция сортировки в памяти ускорена на 25% в некоторых случаях;
    • простаивающий узел СУБД теперь проявляет меньше активности, что полезно при работе в виртуальной машине или при применении в embedded окружении;
    • ускорена работа команды COPY за счет уменьшения операций записи в журнал транзакций и уменьшения количества блокировок;
    • добавлен сбор статистики для массивов, благодаря чему улучшена генерация планов исполнения для запросов с массивами.

>>> Подробности

★★★★★

Последнее исправление: maxcom (всего исправлений: 5)

Вот и отлично. Лишь бы на работе на mssql не согнали.

kerneliq ★★★★★
()

Поддержка типа данных JSON для хранения неструктурированных документов.

Кривой и тормозной EAV уходит в прошлое?

anonymous
()
Ответ на: комментарий от anonymous

Если и валить то лучше на Oracle XE

Я вот с таким трудом с Оракла свалил, а ты человека на него подсаживаешь.

получишь базовый опыт админства настоящих баз данных

настоящих

Ну толсто же.

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

Хотя для разработчика несомненный плюс Оракла - это пакеты. После них писать функции для постгре довольно уныло.

hobbit ★★★★★
()
Ответ на: комментарий от LongLiveUbuntu

А Оракл, ты что! - разрабатывается Серьезной, Ответственной, Уважаемой Корпорацией.

Я бы сказал так - Серьёзной Уважаемой Корпорацией Америки.

hobbit ★★★★★
()
Ответ на: комментарий от hobbit

Главный плюс Оракла в наличии индустрии обучения ему: курсы, сертификаты и т.д. Это решает одну из основны проблем любого бизнеса — кадровую. Но для чуть менее, чем всех «бизнесов» в этой стране это непонятная трата денег. И, соотв., в этой стране Оракл не слишком жалуют.

soomrack ★★★★
()

Хорошая БД. Но проекты на PHP не используют ORM, и полны запросов, написанных только под MySQL. К сожалению, миграция данных проектов на PostgreSQL очень дорогостоящая затея. Поэтому прийдётся и дальше юзать MySQL, хоть PostgreSQL и лучше, чем широко разрекламированная БД от оракула...

lucentcode ★★★★★
()
Ответ на: комментарий от lucentcode

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

Полностью согласен. Начал портировать piwik на postgresql, плюнул и установил рядом mysql.

AlexKiriukha ★★★★
()
Ответ на: комментарий от anonymous

Смотря для чего использовать. Для Web-разработки ваш оракул не очень годится. Пока проект мал, ему и SQLite зачастую хватает:) А потом он просто не втиснется в ограничения Oracle XE, и это уже серьёзная проблемма. Поэтому Web-разработка практически вся завязана на MySQL и PostgreSQL. Последнее время PostgreSQL присутвует на довольно доступном и дешёвом хостинге начального уровня. И на нём даже планируют запускать Joomla 2.5( которая уже работает у некоторых с PostgreSQL). Правда приходиться шаманить с копированием файлов драйвера postgresql из git-хранилища проекта. Joomla - одна из самых популярных CMS на PHP. Если она реализует полноценную поддержку PostgreSQL, другие тоже последуют её примеру.

lucentcode ★★★★★
()
Ответ на: комментарий от AlexKiriukha

Вот-вот. Если команда, разрабатывающая проект сразу работает над поддержкой нескольких БД - это совсем другое дело. Хоть тоже затратное. Вместо одного человека уже несколько в проекте работать над запросами к БД и связанному с ними коду должны, а если разработчик один? Или если проект нужно форкнуть и переписать под личные нужды? Тогда с такой теплотой вспоминаются RoR и Django...

lucentcode ★★★★★
()
Ответ на: комментарий от soomrack

Наш преподаватель по теории СУБД говорил так: " - У вас после выпуска три пути: либо веб-разработка, либо базы данных, либо 1С. А базы данных в России - это Оракл, так что идите учить Оракл, если хотите хорошо зарабатывать."

LongLiveUbuntu ★★★★★
()
Ответ на: комментарий от RedPossum

- Скажите, а армяне лучше, чем грузины? - Да, лучше. - Чем лучше? - Чем грузины.

LongLiveUbuntu ★★★★★
()

Redis+mongodb можно выкидывать?

malbolge ★★
()
Ответ на: комментарий от RedPossum

чем оракл лучше IBM DB2? Не троллинга ради

почти всем. в оракле версионный механизм, оракл не требует эскалации блокировок, на порядок более богатый язык pl/sql, отслеживание зависимостей в коде, больше индексов (bitmap, reverse, FBI, cluster), современная вебная админка, навороты типа flashback, rac и т.п.

anonymous
()
Ответ на: комментарий от anonymous

Если и валить то лучше на Oracle XE И бесплатно и лучшая в мире база + получишь базовый опыт админства настоящих баз данных, можно даже работу хорошую найти.

В чём смысл валить с оракула на оракула?

McArcher
()
Ответ на: комментарий от McArcher

Предлагаю забить на PHP, писать на Сях cgi-шки под Постгре. Давайте перестанем верить телевизору :)

Бедные пэхэпэшники им неведомо что можно писать python или ruby и с легкостью менять базу данных с postgresql на mysql и обратно.

yanka ★★
()
Ответ на: комментарий от Pinkbyte

У меня табличка в 60 гигов ворочается шустро на постгресе так что думаю нескоро упрешься.

Deleted
()
Ответ на: комментарий от yanka

И чем в Python это лучше? Там при работе через DB-API запросы непосредственно передаются клиентской библиотеке конкретной СУБД.

Ttt ☆☆☆☆☆
()
Ответ на: комментарий от yanka

с легкостью менять базу данных с postgresql на mysql и обратно.

Если запросы вида SELECT * FROM table WHERE a>10 - то вообще пофигу какая база. У Постгреса самое вкусное именно в специфических вещах, и никакой ORM и прочий сахар для быдлокодеров тут не поможет.

Saloed
()
Ответ на: комментарий от hobbit

Хотя для разработчика несомненный плюс Оракла - это пакеты. После них писать функции для постгре довольно уныло.

Довольно надуманный плюс. В постгресе можно заменить схемами...

Saloed
()
Ответ на: комментарий от Saloed

Ну а если программа сама создаёт БД? Там уже различия более заметны.

Ttt ☆☆☆☆☆
()
Ответ на: комментарий от anonymous

Версионник это не плюс, это просто другая схема обработки транзакций. Где-то хуже, где-то лучше. Джава на много порядков богаче и быстрее pl sql, зачем писать хранимки на чем-то другом, я не знаю. Современная вебная админка не нужна, везде стоят всякие 9 ораклы, специфические инструменты знать надо по-любому. Наворотов и в db2 хватает.

Legioner ★★★★★
()
Последнее исправление: Legioner (всего исправлений: 1)
Ответ на: комментарий от Saloed

И как?

весело :) На самом деле, если поглубже затянуться маном, то все работает, но не совсем очевидно.

leave ★★★★★
()
Ответ на: комментарий от Legioner

везде стоят всякие 9 ораклы

бррр, вспомнил, как ставил девятку на 5.2 шапку без интернета

leave ★★★★★
()
Ответ на: комментарий от PaRuSoft

Хорошая штука, планирую свалить на неё с MySQL

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

Siado ★★★★★
()
Ответ на: комментарий от McArcher

Делать сайт на сях - это реальный экстрим. Я уж лучше на Ruby переберусь, или на Java. Мне как-то Ruby ближе будет. А ведь видел как-то cgi-шки на ассемблере, когда я им увлекался. Модет, сразу на нём родимом?

lucentcode ★★★★★
()
Ответ на: комментарий от yanka

Бедные пэхэпэшники им неведомо что можно писать python или ruby

Бедные питонщики и рубишники - им неведомо, что под PHP давно уже пишут на 99% с использованием ORM :-)

no-dashi ★★★★★
()
Ответ на: комментарий от no-dashi

под PHP давно уже пишут на 99% с использованием ORM :-)

Ну а lucentcode'у попался тот 1% (ну или 47%), которые без использования ORM.

Ttt ☆☆☆☆☆
()
Ответ на: комментарий от Shaman007

А если заботать Java + Oracle DB, то так вообще + 100 к карме и высокооплачиваемая работа обеспечена.

anonymous
()
Ответ на: комментарий от hobbit

А работу ты как собираешься искать? MySQL используют те конторы у которых туго с деньгами. Postgresql используют полторы конторы. В энтерпрайзе почти 99% ты встретишь MSSQL Server или Oracle.

anonymous
()
Ответ на: комментарий от LongLiveUbuntu

Так скачай Enterprise Edition и играйся с ней до посинения.

anonymous
()
Ответ на: комментарий от anonymous

И как личные предпочтения влияют на возможность трудоустройства?

Ttt ☆☆☆☆☆
()
Ответ на: комментарий от yanka

можно писать python или ruby и с легкостью менять базу данных с postgresql на mysql и обратно

Мадмуазель, подскажите:

1. Кто тот негодяй, что не познакомил вас ни с одной с OMR?

2. В чем смысл с лёгкостью меня одну СуБД на другую на уже разрабатываемом проекте? Это как часами выбирать в магазине между ножом с красной ручкой и с синей ручкой, взять с синей и потом долго страдать, что он на кухне не гармонирует с цветом свёклы?

3. Кстати, какую лучше брать свеклу для борща: крупную или мелкую?

r_asian ★☆☆
()
Ответ на: комментарий от r_asian

2. В чем смысл с лёгкостью меня одну СуБД на другую на уже разрабатываемом проекте? Это как часами выбирать в магазине между ножом с красной ручкой и с синей ручкой, взять с синей и потом долго страдать, что он на кухне не гармонирует с цветом свёклы?

Разные причины. Например, при увеличении нагрузки. Старая СУБД может быть плохо масштабируема.

1. Кто тот негодяй, что не познакомил вас ни с одной с OMR?

Ну так не познакомили не его, а тех разработчиков, плодами работы которых ему приходится пользоваться. И да, кому-то в каких-то условиях, возможно, работать непосредственно с SQL-запросами более удобно.

Ttt ☆☆☆☆☆
()
Ответ на: комментарий от Ttt

Например, при увеличении нагрузки. Старая СУБД может быть плохо масштабируема.

Масштабировать систему путём «перехода на более лучшую СУБД»? Убивать, труп насиловать, обоссывать и оставлять на съедение кабанам.

r_asian ★☆☆
()
Ответ на: комментарий от r_asian

Ну а если старая СУБД не справляется с возросшей нагрузкой? Когда проект только создавали, не думали, что будет такая нагрузка. А вот она появилась. Все остальные компоненты справляются нормально, а СУБД — нет.

Ttt ☆☆☆☆☆
()
Последнее исправление: Ttt (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.