После года разработки представлен (http://www.postgresql.org/about/news/1481/) релиз новой стабильной ветки СУБД PostgreSQL 9.3. Кроме продолжения работы по наращиванию функциональности в процессе подготовки нового выпуска большое внимание было уделено увеличению надёжности, отказоустойчивости и интеграции с другими СУБД.
Основные улучшения (http://wiki.postgresql.org/wiki/What%27s_new_in_Postgre...):
- Возможность (http://wiki.postgresql.org/wiki/What%27s_new_in_Postgre...) выполнять операции обновления данных (UPDATE) в представлениях (VIEW), формируемых на основании выборки через оператор SELECT и ранее доступных только на чтение. Применение операции UPDATE для представлений допускается с определёнными ограничениями, например, поддерживаются представления только с одной таблицей или другим представлением в блоке FROM, не содержащие в теле операций WITH, DISTINCT, GROUP BY, HAVING, LIMIT и OFFSET, и без использования UNION, INTERSECT и EXCEPT на первом уровне вложенности.
- Новая конструкция "MATERIALIZED VIEW", позволяющая определять представления с кэшированием заданного в представлении запроса в отдельной физической таблице с последующей выборкой данных из этой таблицы, вместо осуществление повторных запросов при каждом обращении к представлению;- Включён (http://www.opennet.me/opennews/art.shtml?num=36700) дополнительный набор средств для преобразования и манипуляции данными в формате JSON. В частности в дополнение к ранее представленному типу данных JSON добавлены функции для генерации данных в формате JSON из данных в других форматах, функции парсинга данных в формате JSON и встроенные операторы для обработки JSON-данных, позволяющие извлекать поля, менять отдельные значения, создавать записи на основе JSON-данных;
- Доступные (http://wiki.postgresql.org/wiki/What%27s_new_in_Postgre...) на запись внешние таблицы, позволяющие помещать данные в другие БД;
- Средства для хранения контрольных сумм для контроля целостности данных в БД и выявления повреждений файловой системы;- Новый драйвер pgsql_fdw для логического объединения содержимого БД на нескольких серверах, в том числе для организации бесшовного полного доступа к БД на внешних серверах PostgreSQL;
- Новый упрощённый синтаксис для определения рекурсивных представлений (CREATE RECURSIVE VIEW);
- Поддержка ключевого слова LATERAL (http://www.postgresql.org/docs/devel/static/queries-table-ex...) для определения подзапросов в блоке FROM, ссылающихся на содержимое полей, полученных в процессе выполнения других подзапросов в процессе выполнения операций по слиянию таблиц (без LATERAL каждый из подзапросов выполняется независимо и не может учитывать данные других подзапросов);
- Использование q-gram индексов (модуль pg_trgm) расширено на поиск по регулярным выражениям (http://www.depesz.com/2013/04/10/waiting-for-9-3-support-ind.../) (операции LIKE/ILIKE могут использовать индексы, начиная с версии PostgreSQL 9.1);
- Произведен (http://wiki.postgresql.org/wiki/What%27s_new_in_Postgre...) переход с использования SysV shared memory на POSIX shared memory и mmap, что упрощает установку и конфигурацию, и избавляет от необходимости настройки таких параметров, как SHMMAX и SHMALL. Значительно сокращено потребление разделяемой памяти (SysV shared memory), что избавляет пользователей крупных систем от дополнительного тюнинга;- Сокращено время распространения реплик, а также значительно ускорена передача управления от запасного сервера к первичному;
- Увеличена производительность и улучшена система блокировок для внешних ключей;- Обеспечена возможность ускорения резервного копирования через запуск pg_dump в параллельном режиме, позволяющем выполнять бэкап одновременно нескольких таблиц;
- Поддержка разбиения конфигурации на серию отдельных файлов, размещаемые в одной директории и подключаемых через директиву 'include_dir';
- Добавлена утилита pg_isready для проверки доступности БД;
- Новый оператор "COPY FREEZE" для минимизации нагрузки на систему ввода/вывода при копировании больших объемов данных;
- Возможность создания пользовательских фоновых обработчиков, для автоматизации выполнения операций с БД (например, выполнение мониторинга или запуск типовых операций через определённые интервалы времени);
- Новая директива lock_timeout для ограничения продолжительности ожидания освобождения блокировки.
URL: http://www.postgresql.org/about/news/1481/
Новость: http://www.opennet.me/opennews/art.shtml?num=37866
"Увеличена производительность и улучшена система блокировок для внешних ключей" - это мне нравится
а я люблю господина PG ещё больше!
Ку!
А у тебя есть Малиновые Штаны ?
По моему PosgreSQL становится перегруженной фичами СУБД.
Эти фичи нужны для наращивания облачной коммутации API/RESTful/IaaS/etc...>/dev/null
Как MySQL?
Как можно "перегрузить" фичами СУБД, если эти фичи напрямую связаны с ее функциональностью? Радоваться надо что фич все больше.
Месье, по-видимому, беспокоится о том, что добавление новых фич приведёт к усложннению кода, что может стать причиной увеличения числа ошибок.
Количество ошибок в основном увеличится из-за ошибок в самих новых фичах. Это неизбежно, да. Но на то он и опенсорсный проект чтобы баги всем миром ловить. Все одно лучше чем проприетарщина.
по этому нужно завернуться в белую простынку и уползти сразу на кладбище.эти фичи пилят хрен знает сколько, некоторые не один год.
К сожалению надо признать что многие из этих фич на поверку оказываются несколько недоделанными (если сравнивать например с ораклом, а не mysql). Те же триггеры и хранимки вообще, матпредставления, рекурсия, пакеты которые в пг якобы хорошо заменяются схемами, кластеризация и пр. мелочи. А некоторых реально нужных вещей так и вовсе нет, автономные транзакции, те же пакеты, синхронная репликация на несколько бд.. Так что до перегруженности фичами поверьте еще далеко) впрочем конечно если вы реально бдшник, и не рассматриваете бд как просто хранилище.
Заведомая неправда.
Да-да, конечно ведь вменяемые range partitions (в postgres они делаются совершенно неприличным костылем), реверсивние индексы, механизмы вроде secure files, средство резервирования/восстановления уровня rman (т. е. с block recovery), поддержка hugepages, AWR и многое другое, что лень перечислять, никому не нужно? Ясен пень, что если ты ничего не понимаешь в БД, то разница между ораклом и postgres только в бесплатности последнего. Oracle - не "массовая" СУБД, выигрыш от его использования можно получить, только хорошо разбираясь в реляционных БД вообще, и в самом оракле в частности.
Враньё насчёт hugepages бросается в глаза как не знаю что. А AWR само по себе вообще чисто оракловая фича. Оно хоть и полезно, но отсутствие аналога даже в DB2 наводит на размышления о возможных скрытых минусах.
[TROLLFACE]
Было дело, у меня на глазах новосибирские "ораклисты" установили следующий пудинг:
- M$ Windows 2003 (дело было ~ в 2007г.)
- Oracle 11.чего-то там (я не ораклист и суть не в этом). БД afair на ntfs-партиции.
- !sic KAV, сиречь антивирус КасперскогоНа вопрос "вы чо?" промычали что-то типа "так положено".
[/TROLLFACE]Это я к тому, что шанс нарваться на долбоклюев в случае с Oracle ничуть не меньше, несмотря на завышенный порог вхождения (или благодаря ему?).
Постгря, несмотря на тонну недостатков (но над многими очень активно работают, что реально радует), предоставляет офигенный комьюнити и внятную документацию - только бы голова думала. И уже сейчас для многих проектов, даже довольно "тяжёлых", ее ХВАТАЕТ.
> Да-да, конечно ведь вменяемые range partitions (в postgres они делаются совершенно неприличным
> костылем)Согласен
>, реверсивние индексы,Не нужны, в силу другой архитектуры СУБД.
>механизмы вроде secure files, средство резервирования/восстановления
> уровня rman (т. е. с block recovery), поддержка hugepages, AWR иПоследние 2 фичи сомнительны, есть гораздо более нужные вещи, которых нет в postgresql,
а это - плюшки.
> многое другое, что лень перечислять, никому не нужно? Ясен пень, что
> если ты ничего не понимаешь в БД, то разница между ораклом
> и postgres только в бесплатности последнего.А было бы неплохо перечислить. Потому, что ИМХО, 2/3 фич из того, что есть в оракле,
но нет в постгрисе почти не используются.
>Oracle - не "массовая" СУБД,
> выигрыш от его использования можно получить, только хорошо разбираясь в реляционных
> БД вообще, и в самом оракле в частности.С этим согласен
> Да-да, конечно ведь вменяемые range partitions (в postgres они делаются совершенно неприличным
> костылем), реверсивние индексы, механизмы вроде secure files, средство резервирования/восстановления
> уровня rman (т. е. с block recovery), поддержка hugepages, AWR и
> многое другое, что лень перечислять, никому не нужно? Ясен пень, что
> если ты ничего не понимаешь в БД, то разница между ораклом
> и postgres только в бесплатности последнего. Oracle - не "массовая" СУБД,
> выигрыш от его использования можно получить, только хорошо разбираясь в реляционных
> БД вообще, и в самом оракле в частности.Позиция типа "Я хочу оракл, но бесплатно, а если бесплатно нет того, что есть в оракле, то Г...но". Ясно-понятно
> Позиция типа "Я хочу оракл, но бесплатно, а если бесплатно нет того,
> что есть в оракле, то Г...но". Ясно-понятноМожно было бы ответить "ок, залей свой патч с недостающим функционалом в репозиторий", или
"заплати программистам, которые выложат патч".
Но не буду.
Оракловые пакеты следует сравнивать не со схемами, а с extensions в postgresql.
Да, пока что бедновато, но это только пока. Вот допилят отслеживание зависимостей на уровне базы(чтоб из базы дерево можно было посмотреть), чтоб зашифровывать код ХП можно было,
ну и переменные контекста чтоб в расширении были - цены не будет.
Хотя последнее лично мне не нужно.
>чтоб зашифровывать код ХП можно было,этого никто делать не собирается.
Features We Do Not Want
Obfuscated function source code (not wanted)Obfuscating function source code has minimal protective benefits because anyone with super-user access can find a way to view the code. At the same time, it would greatly complicate backups and other administrative tasks. To prevent non-super-users from viewing function source code, remove SELECT permission on pg_proc.
> этого никто делать не собирается.И чёрт с ним. Тоже редко кому нужно.
Вот с зависимостями расширений там печаль, да.
Без этого неудобно пользоваться механизмом при разработке.
Правду говоришь, подтверждаю как админ Oracle 9i, 10g, 11g и Postgresql 9.*
согласен. одних partitions уже достаточно, чтобы Postgres не встал рядом с Oracle.
> согласен. одних partitions уже достаточно, чтобы Postgres не встал рядом с Oracle.Согласен! Рядос с Оракелем всё обвисает и сдувается.
ЗЫЖ В джавва уже есть partiotions?
не становится. Только начинает набирать функционал нормальной РСУБД
По-моему, ёпта!
>>> Произведен переход с использования SysV shared memory на POSIX shared memory и mmap, что упрощает установку и конфигурацию, и избавляет от необходимости настройки таких параметров, как SHMMAX и SHMALL. Значительно сокращено потребление разделяемой памяти (SysV shared memory), что избавляет пользователей крупных систем от дополнительного тюнинга;Красавцы!
>>>> Произведен переход с использования SysV shared memory на POSIX shared memory и mmap, что упрощает установку и конфигурацию, и избавляет от необходимости настройки таких параметров, как SHMMAX и SHMALL. Значительно сокращено потребление разделяемой памяти (SysV shared memory), что избавляет пользователей крупных систем от дополнительного тюнинга;
> Красавцы!Знакомы эти переменные, так их перетак.
Эх. Ещё бы админку удобную найти, чтобы свои велосипеды не напрягаясь админить. Пока не нашёл, поэтому до сих пор использую MySQL. А так много интересно есть в postresql, чтобы облегчить себе жизнь.
Если кто подскажет утилиту для администрирования, буду благодарен. phpPgAdmin не предлагать. Слабоват.
pgadmin.org
GNU + psql
EMS SQL Manager for PostgreSQL. Лучшее что есть, но тоже не без косяков, подглюкивает. Больше всего меня умеляет глюк когда периодически перестает работать Ctrl+Ins/Shift+Ins)) надо перещелкивать вкладку после чего оно восстанавливается, похоже ребята сильно начудили с фокусами, сколько в саппорт не отписывал - бесполезно. Но по совокупности реально лучше нет.
"умиляет", проверочное слово "умильный"
Спасибо. У меня в школе по русскому трояк был.
> Спасибо. У меня в школе по русскому трояк был.Аналогично, коллега. Однако, после того, как стал помогать делать уроки по русскому ребёнку - понял, что логики там не меньше, чем в математике. Даже исключения из правил выглядят вполне логичными.
Ещё бы, язык же в Киеве проектировали
теперь этим гордятся? отемпора омореса на вас нет!
Может он белеет, не путайте человека!
> EMS SQL Manager for PostgreSQL. Лучшее что есть, но тоже не без
> косяков, подглюкивает. Больше всего меня умеляет глюк когда периодически перестает работать
> Ctrl+Ins/Shift+Ins)) надо перещелкивать вкладку после чего оно восстанавливается, похоже
> ребята сильно начудили с фокусами, сколько в саппорт не отписывал -
> бесполезно. Но по совокупности реально лучше нет.Тоже писал - посылают. Мотивируют тем, что пользуюсь бесплатной версией.
Хотя каким это боком связано с багом - хз.
Navicat???
Вполне отлично работает.
это та что выглядит как уг под маком и линем?
11 версия отлично выглядит и под линукс и под мак и под винду
Всегда выглядела как УГ.. И особенности работы буфера обмена с wine-приложением вымораживают (впрочем, в pgadmin буфер обмена тоже через пень-колоду работает - что скопировано там, потом не в каждое приложение получается вставить).Скачал 11 версию - она вообще не запускается, start_navicat просто завершается, без ругани и ошибок. 19-ая федора, 32-х битные либы совместимости стоят. Если ей какой-то особенной библиотеки не хватает, могли бы написать в требованиях, или нормальный пакет выложить, по которому зависимости видно. Ну или на крайняк при запуске из скрипта ругнуться. Так нет же - не удивлюсь, если эти проприетарщики кроме какой-нибудь старой убунты вообще ни на чем это не тестировали и не ведают, что линукс убунтой не ограничивается. Причем 32-х битной наверняка - в отличие от винды и мака, под которые можно скачать 64-х битную сборку, под линь дают только 32-х битные виндовые бинарники в пакете с 32-х битным же вайном. И потом они надеются, что кто-то будет покупать у них версию под линукс??
Очевидно что /usr/local/bin/psql
GUI не нужны же.
Ну-ну... Если база не больше 100 МБ, то еще можно что-то гуевое использовать. Но если больше, то бекап/ресторе базы в десятки, а то и сотни, раз медленее, чем прямо shell-скриптом (естественно, сервер не на Винде). Но если сервер на Винде - используйте MS SQL, и только его...
сервер на Винде? только в дурдоме если
> сервер на Винде? только в дурдоме еслиНу а что? А если 1C, то на чем еще сервер?
дядя даже богомерзкая 1C уже давно на GNU/Linux, вылезай из анабиоза
Ты это фрайчайзикам 1С-ки скажи. Только Windows-сервер. Только терминальный доступ. Только AD. Вот истина в понимании 1С.
>Но если сервер на Винде - используйте MS SQL, и только егоКартинка с названием "Paying For SQL Server"
http://media.tumblr.com/6975654124d5729b22abb6c97bf3010d/tum...
> Ну-ну... Если база не больше 100 МБ, то еще можно что-то гуевое
> использовать. Но если больше, то бекап/ресторе базы в десятки, а то
> и сотни, раз медленее, чем прямо shell-скриптом (естественно, сервер не на
> Винде). Но если сервер на Винде - используйте MS SQL, и
> только его...Бэкап выполняется абсолютно столько же запущенынй из pgadmin b из любых скриптов, так как в любом случай выполняется pg_dump. Иллюзия замедления, возможно, из-за того, что pgadmin незаметно соединяется с удалённой базой и делает из неё бэкап на локальную систему - тем же pg_dump , но из-за сетевых задержек это получается медленно.
ssh и psql - самая удобная админка!
не осилив это юзать mysql... фу!
Скажите высунувшемуся из линукса, а что клиентская утилита mysql разве с gui?Что-то
не замечал.
mysql'ный консольный клиент ощутимо уё...щней
За пару дней написал клиент к мусклю с libmysql с gui на X11+OpenGL.Есть rpm пакет.
Navicat Premium
А ещё полнотекстовый поиск там должны были допилить до скоростей, со сфинксом сравнимых... Допилили? Кто-нибудь знает?
> А ещё полнотекстовый поиск там должны были допилить до скоростей, со сфинксом
> сравнимых... Допилили? Кто-нибудь знает?Были тормоза с индексами.
Но с 9.1 версии их не наблюдал.
Как сейчас - пока не тестил.
