LINUX.ORG.RU

PostgreSQL 9.0

 , ,


0

0

На зеркалах уже появился tarball завтрашнего релиза одной из ведущих открытых реализаций реляционной СУБД - PostgreSQL 9. Данное обновление преподносит пользователям огромное число новшеств, главные из которых:

  • Простая в использовании репликация
  • Массовое управление правами доступа
  • Различные улучшения в хранимых процедурах, включая анонимные блоки кода
  • Exclusion constraints - обобщенный аналог ограничения уникальности, позволяющий строить более сложные условия
  • Откладываемые ограничения уникальности (deferrable unique constraints)
  • Новая реализация VACUUM FULL. Теперь команда полностью перезаписывает таблицу и индексы, устраняя проблему роста индексов и работает быстрее предыдущего алгоритма
  • Новая быстрая реализация LISTEN/NOTIFY
  • Различные улучшения производительности, в том числе исключение ненужных операций JOIN (что улучшает производительность некоторых ORM)

Также появился встроенный модуль passwordcheck для анализа стойкости паролей, аутентификация через RADIUS и LDAP, Python3 в PL/Python и многое другое.

>>> Changelog

★★★★★

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

Ответ на: комментарий от nebeda_x

> были решения про полный бекап

dump-restore — единственный документированный способ при смене даже минорной версии. И это правильно.

baka-kun ★★★★★
()
Ответ на: комментарий от vertexua

>Если профита прямого нет, то MySQL кажись быстрее

уточнись сначала чтобы не казалось...

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

Ви таки тоже за г'асовую чистоту?

после полутора лет в бангалоре я стал рассово не толерантен ;)

комичность момента, запечатлённого на фотографии, понятна только знакомым с ситуацией более детально

именно так, хотелось передать атмосферу

p.s. все эти комменты уже стали не совсем уместны, так как начинались, когда тема была в неподтвержденных, предлагаю «на не по делу» забить.

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

Тогда непонятно зачем товарищу анонимусу, потребовалось множество запросов для установки прав доступа. Достаточно назначить роль и всё.

anonymous
()

Отличная новость для утра понедельника! Даешь открытый оракал!

exst ★★★★
()

очень хорошо, ставим на тестовую машину и смотрим

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

может изменение количества таблиц, точнее может ответить только автор.

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

> разумеется ни один initdb не помогает, база уже есть и живёт с 8.3 кажись версии, жила и на 9.0b, 9.0stable

ну так формат хранилища изменился. и вообще, при изменении мажорной версии dump/restore - штатная процедура. если требуется не останавливать базу, то тот же dump/restore можно сделать слонами.

опять же, http://pgfoundry.org/projects/pg-migrator/ - может помочь. а может и не помочь.

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

> Тогда непонятно зачем товарищу анонимусу, потребовалось множество запросов для установки прав доступа. Достаточно назначить роль и всё.

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

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

>ничего особенно *смешного* в спящем индусе не вижу
ну да - обычные автоматические генераторы говнокода

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

Цитата: Прав хватало постгресовских, но при добавлении нового пользователя, или при изменении структуры таблиц, приходилось делать жуткие извращения вроде селекта всех названий таблиц и генерации запроса из результата. А теперь можно просто одной командой.


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

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

> ну да - обычные автоматические генераторы говнокода

Это точно. На моей памяти только старый фоксист-клипперист («блочное копирование заменяет алгоритмическое программирование») и команда ораклистов (в разное время) могли написать элементарную процедуру так, что получилось два вложенных полных сканирования по огромной вьюшке, прямое произведение этой вьюшки на не очень маленькую таблицу, и полное сканирование результата. Для получения ключа одной строчки из маленькой таблички.

Команда ораклистов /неделю/ оптимизировала свой код: меня как заказчика ну никак не устраивало время 60..90 секунд на операцию, которая должна выполняться почти по каждому чиху интерфейса. В результате я поспорил в присутствии CEO разработчика с их менеджером проекта (там уже на повышенных тонах все шло — срыв сроков) на недельную зарплату всей группы (неделю же ковырялись), что прямо сейчас «сделаю зашибись». Первое же внутреннее соединение по первичным ключам оставляет десяток строк, процедура выполняется десяток миллисекунд. CEO оказался честным человеком (в отличие от менеджера) — жена у меня теперь на новой машине детей возит.

baka-kun ★★★★★
()

одной из ведущих => ведущей

fixed

даешь встроенный Temporal!

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

Нет, пока не умеет. Хотя, впрочем, надо конечно обновиться, если есть версия новее.

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

> В оракле есть ...

В оракле есть оптимизатор запросов, до которого свободным DBMS ещё очень долго идти. Я прошёл путь от 7.3.4 до 11, наблюдал развитие оптимизатора и сравнивал периодически с MySQL (тьфу!) и PostgreSQL. Постгрес весьма кошерен по замыслу, но нормально у меня оптимизатор выдаёт запросы только когда вся база кешируется в памяти и он может безболезненно делать Nested Loops.

P.S. Да, я любитель SQL-запросов на 23 строчки...

Casus ★★★★★
()
Ответ на: комментарий от baka-kun

> Команда ораклистов /неделю/ оптимизировала свой код...

Да кто бы спорил. Но у оракла при наличии мозга можно сделать «зашибись», а в MySQL бывает что и нельзя. Конкуренция между insert и select так никуда и не делась, даже в innoDB, временные view скорее для «что б были», реально по ним не бывает индекса, и соединение только full scan'ом, и как не выкорёживайся ни с запросом, ни со структурой таблиц, хорошего плана не получить. Единственный быстрый запрос в MySQL звучит как «select * from table where id = ?», всё, что сложнее, подразумевает крохотные и ненапряжные базы. На 20Gb RAM тачке 200 процессов, ненапряжно апдейтящих таблицу, тормозят именно на MySQL, хотя WA при этом 0.3%.

Casus ★★★★★
()

Те, кто уже прочитал и пощупал: блобы (oid) реплицировать уже умеет? Или необходимы дополнительные приседания.

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

полна роисся талантами способными одним запросом нагнуть любую бд

Написать плохой запрос не проблема, я очень хорошо в курсе. Проблема написать хороший запрос для конкретной DBMS и конкретной версии DBMS. Я каждый свой запрос проверяю на план выполнения, поэтому очень большой опыт имею.

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

А так да. лично я долго ждал: * репликацию * индекс по столбцам * сразу включенный PL/pgSQL вещь приятная.

Надеюсь они сумели уменьшить резмеры файлов лога транзакций. А то с этим были проблемы.

(Репликацию пока не пробовал)

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

P.S. Да, я любитель SQL-запросов на 23 строчки...

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

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

>Понятно, что первоначально для роли необходимо назначить права на таблицы, но затем при _добавлении нового пользователя_ достаточно назначить ему роль или включить в нужную группу. Для этого достаточно одной команды.

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

//Тот анонимус.

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

BDB и InnoDB поддерживают транзакции.

mysql> SET AUTOCOMMIT=0;
mysql> INSERT INTO ... 
mysql> INSERT INTO ...
mysql> INSERT INTO ...
mysql> SELECT * FROM ...
mysql> ROLLBACK
mysql> SELECT * FROM ...

В таблицах типа MyISAM использование транзакций недоступно, но их можно эмулировать при помощи операторов LOCK TABLES и UNLOCK TABLES.

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

>InnoDB поддерживают транзакции.

И от этого исчезает главное преимущество mysql - высокая скорость чтения, которая есть в MyISAM.

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

... или просто стали использовать ORM...

ORM - мягко говоря не работает под высокой нагрузкой, оверхед великоват

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

но ОRМ не серебрянная пуля и не повод городить многоэтажные sql (тем более что их городит по хорошему сам ORM)

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

> Да кто бы спорил. Но у оракла при наличии мозга можно сделать «зашибись»

Антон, да кто бы спорил. Так оно и есть, как, собственно, и у постгреса.

в MySQL бывает что и нельзя

Периодически находит посмотреть, во что оно превращается, но так же быстро проходит. Не рассматриваю MySQL как что-то большее, чем относительно небольшое read-mostly хранилище с элементарными запросами. И с языком там проблемы, и с ACID... Ну его нафиг, постгрес на подавляющем большинстве задач быстрее и надежнее. …и версионник.

Единственный «минус» постгреса — дорогой коннект, но пулы никто не отменял.

Единственный быстрый запрос в MySQL звучит как «select * from table where id = ?»

Ещё count(*) на MyISAM. :) Кстати, «select * from table where something = ?» уже не так быстро, если на something не первичный ключ.

baka-kun ★★★★★
()
Ответ на: комментарий от tailgunner

> «Любитель» - значит «пишу их когда надо и когда не надо»?

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

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

> не часто такое реально нужно

Да, не часто.

обычно это косяки в дизайне или слишком жёсткое следование «нормальной форме» в ущерб производительности.

А это уже спекуляции. Ну и «нормальная форма» часто вполне обоснована. Нарушать нормализацию где надо я умею.

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

В таблицах типа MyISAM использование транзакций недоступно, но их можно эмулировать при помощи операторов LOCK TABLES и UNLOCK TABLES.

Это же просто смешно, отборная CS сатира.

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

>В таблицах типа MyISAM использование транзакций недоступно, но их можно эмулировать при помощи операторов LOCK TABLES и UNLOCK TABLES.

А ещё СУБД можно эмулировать при помощи grep, find и текстовых файлов.

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

> Ещё count(*) на MyISAM. :)

О, да! ;)

Кстати, «select * from table where something = ?» уже не так быстро, если на something не первичный ключ.

Ну я в имени поля «id» подразумевал первичный ключ, как бы само собой.

Единственный «минус» постгреса — дорогой коннект, но пулы никто не отменял.

Ну, кстати, у оракла он поди ещё дороже. По крайней мере раньше с дедикейтед серверами время на коннект было заметно, сейчас вроде не так заметно, но не замерял давно. С другой стороны, меня бесит автодисконнект мыскуля каждые 24 часа.

На счёт посгреса: начиная с версии 8.4 я его ставлю везде, где раньше поставил бы мыскуль. Так что целиком поддерживаю релиз 9-ки, особенно если там сделали человеческую репликацию. Мне пока не надо, быкапы раз в 15 минут спасают ;) Но может понадобиться.

Язык постгреса (DDL+sequences), по сути диалект оракла, мне гораздо больше нравится, чем язык мыскуля, который по сути диалект Sybase/MSSQL. Но я тут предвзят, я с ораклом раньше познакомился.

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

> вертухай, ты дурак?

Тянет на оскорбление участника дискуссии, и следом бан айпи.

как греп может быть быстрее субд?

Бывает и такое. Запросы типа [r]like в DBMS не всегда эффективны, а фрагментированная таблица может храниться не так оптимально как линейный текстовый файл.

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

> Тогда непонятно зачем товарищу анонимусу, потребовалось множество запросов для установки прав доступа. Достаточно назначить роль и всё.


anonymous (20.09.2010 9:04:02)

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

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

автодисконект никак не вырубить? Тоже достал

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

> Тянет на оскорбление участника дискуссии, и следом бан айпи.

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

про «греп на стероидах» — да, я неточно вырзился.

PS: пользователь постгреса с 7.4.

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

>В таблицах типа MyISAM использование транзакций недоступно, но их можно эмулировать при помощи операторов LOCK TABLES и UNLOCK TABLES.

Велика Росия-матушка и извращенцев в ней не счесть. А может проще юзать то что уже изкаробки

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

А это уже спекуляции.

поверь мне - я на тебя ничуть не наезжал ;)

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

> (тем более что их городит по хорошему сам ORM)

О чем я собно и написал >_<

sv75 ★★★★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.