LINUX.ORG.RU

UPSERT и не только. Что ждать от PostgreSQL 9.5?

 


6

6

2 июля вышла PostgreSQL 9.5 alpha. Среди основных улучшений можно отметить:

  • BRIN-индексы («индексы блоковых зон»), позволяющие сверхкомпактно индексировать очень большие таблицы.
  • Существенные оптимизации скорости сортировки и хэширования в памяти.
  • Автоматизированное управление размером лога транзакций.
  • INSERT ... ON CONFLICT UPDATE, также известный как «UPSERT».
  • Аналитические функции CUBE и ROLLUP.
  • Безопасность строкового уровня (Row-Level Security, RLS).
  • Новые манипуляционные возможности (функции и операторы) для типа данных JSONB.
  • Инструмент pg_rewind и другие улучшения репликации и средств повышения отказоустойчивости.
  • Множественные улучшения в механизм Foreign Data Wrappers, включая IMPORT FOREIGN SCHEMA.
  • Существенные улучшения масштабирования на системах с большим количеством процессорных ядер и оперативной памяти.

Статья «UPSERT и не только. Что ждать от PostgreSQL 9.5?» расскажет о некоторых новинках подробнее.

Скачиваем

What's New (англ.)

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

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

надо тыкать в pgsql и декартовы прозведения с теориями множеств

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

Думаю многие потыкавшись в баги pgadmin забивают на эту базу данных даже не добравшись толком до неё.

Чёрт! Через 7 лет использования постгреса я узнал, что кроме psql бывает ещё и вебморда! Собсна, нафига она была бы мне нужна...

Держись за кресло покрепче. pgadmin - это _не_ вебморда!

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

Держись за кресло покрепче. pgadmin - это _не_ вебморда!

всё равно не понимаю зачем мне что то кроме psql, превосходнейший клиент! учитывая, что закалялся я в sql*plus...

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

но автотюнинг актуален все-же

согласен. было бы неплохо.

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

кроме psql бывает ещё и вебморда!

Какая еще к лешему веб-морда. Я про приложение pgadmin. Что-то в стиле «sql server management studio». psql это надо быть слишком задротом и не ценить свое время.

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

Естественно пробовал. Более чем рабочая схема, особенно когда нужны поиски по множеству атрибутов, которые заранее неизвестны.

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

ФС можно рассматривать как некоторую СУБД, спору нет.

ФС можно рассматривать как «движок» хранения данных, а не СУБД. ОС можно рассматривать как СУБД.

при чём тут постгрес?

Постгрес - это частный случай ОС :-)

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

У постгреса есть большая проблема на мой взгляд - бесплатные средства для работы с ней еще та галиматья.

А что, если купить качественный инструмент?

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

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

А когда такие поиски не нужны, а нужен поиск по конкретным атрибутам с типами, отличными от строкового? Тут все «достоинства» и вылазят: и просадка производительности, и многоэтажные запросы, и проблемы с оптимизацией этих запросов.

И почему EAV более «реляционна» чем создание таблицы или хранение структурированного blob? С blob понятно, они находятся примерно в одной категории, можно поспорить, кто «реляционее». Но с обычной таблицей?..

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

Это с одной стороны, а с другой, у тебя даже 1нф не выполняется.

Как это — не выполняется? Еще как выполняется! Блоб с точки зрения РБД — атомарен. Я даже спорить по данному вопросу не собираюсь ввиду бесперспективности, т.к. мы просто упрёмся в аналог дисциплины спецолимпиады как моделировать ФИО:«Иванов Иван Иванович» или («Иванов», «Иван», «Иванович») или («Иванов», «Иван Иванович»).

При 1НФ нормализации нужно знать когда необходимо остановиться, а то можно донормализоваться до разборки строк на кодпойнты, кодпойнтов — на байты, а байт — на биты.

Кстати, решение «динамическая таблица на сигнал» — вообще антиидиома. Как и таблица «атрибуты документов». Но да, применяется широко.

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

А зачем нужен pgadmin, если есть psql?

Из GUI мне лично очень понравился плагин Database из IntelliJ IDEA (есть в виде отдельного продукта 0xdbe).

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

Естественно пробовал

т.е. объёмы были смешные и производительность не волновала. да, так это будет вполне работать.

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

Что задротского в psql? Ладно, секретарши не осилили SQL, для которых он создавался, но сегодня уже что, программисты, работающие с БД, не осиливают SQL?

Чего конкретно не хватает в psql? Я могу представить себе только автодополнение имён таблиц и столбцов. Но во всяких mysqladmin этого тоже нет. Там такое же текстовое окошко для ввода SQL.

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

psql это надо быть слишком задротом

ПНХ. я ценю своё время, у меня всё получается в psql.

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

кстати toad для слона не помешал бы

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

ФС можно рассматривать как «движок» хранения данных, а не СУБД. ОС можно рассматривать как СУБД.

Всё можно рассматривать движком хранения данных. a[0] = «блабла» — тоже движок хранения данных. А вот что такое ОС стоит всё-таки ознакмиться с формальными определениями, а не выдумывать самостоятельно.

P.S. и чего блин капча злая сегодня? уйду нафиг отсюда.

anonymous ()

Redis и MongoDB не нужны, потому что Постгрес проще, удобнее и быстрее. Если бы Ruby был написан на хранимках в Постгресе, он работал бы в три раза быстрее и не падал. Ноду пришлось писать на V8, потому что джаваскриптеры не поняли лицензию Постгреса, а Erlang появился, потому что кто-то просто не умеет пользоваться триггерами и хранимками. K&R после создания C пришлось писать UNIX, потому что они хотели, конечно, написать Постгрес, но ему было не на чем запускаться. C++0X появился только для того, чтобы умные люди перестали писать на C и перешли на Постгрес. Разработка файловых систем нового поколения часто тормозится (особенно ZFS), потому что люди понимают, что с какой стороны не подходи и что не делай, а из-за требований нормальной транзакционности все равно получается Постгрес! Сам Постгрес написан на хранимках Постгреса, мейкфайл выполнен в виде дампа Постгреса, и собирается Постгрес Постгресом.

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

Что задротского в psql?

И действительно, что задротского в лысой командной строке. Даже не знаю что сказать... Ну наверно всё!

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

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

Постргрес не нужнен, потому что есть Постгрес. :-)

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

C++0X появился только для того, чтобы умные люди перестали писать на C и перешли на Постгрес.

Цепепе-ноль-икс - это такой мощный язык, что Постгрес не нужен :-)

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

И действительно, что задротского в лысой командной строке. Даже не знаю что сказать... Ну наверно всё!

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

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

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

Миллионы SQL-запросов прекрасно хранятся в файлах. В psql можно загрузить запрос из файла, можно его передать в vim для редактирования (который тебе подсветит всё, что угодно), уж выполнить запрос-то и подавно можно.

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

Там есть автодополнение по табу

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

Первое, что я делаю в IDE это отключаю попугайскую расцветку. Потому что отвлекает.

Твой аватар попугайский и отвлекает. Отключай.

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

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

Так и я пользуюсь в редких случаях для минорных задач. Но это где-то так же эффективно, как пахать лопатой поле. Можно, кто же против. Дело не в возможности. А работать с многостраничным кодом без подсветки, ну... могу только посочувствовать. Причем твоим работодателям в первую очередь.

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

Чего конкретно не хватает в psql?

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

Там такое же текстовое окошко для ввода SQL.

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

psql замечательный инструмент, но это только часть, кирпичик из которых ты строишь свою систему разработки сам, как минимум тебе нужен ещё текстовой редактор. Кто-то готов этим заниматься, а кто-то нет и ему проще использовать готовые системы, хотя бы тот же pgadmin

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

Синтаксис SQL это для каких-нибудь кобольщиков. Нормальный человек чем реже его видит тем лучше себя чувствует.

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

Синтаксис SQL это для каких-нибудь кобольщиков. Нормальный человек чем реже его видит тем лучше себя чувствует.

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

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

И даже внутри текстового литерала в функции на plpython?

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

Странно ждать дополнения в PL/Python от клтиента MySQL, не находите?

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

Странно обсуждать клиент MySQL в теме о postgres, не так ли?

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

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

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

И не менее странно задавать вопрос той, кто не начинал это обсуждение ;-)

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

Раз не ты начинала, значит участие в обсуждении не считается. Логично.

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

у 7 нянек, ну, дальше Вы знаете для 1С 4 специалиста. ню-ню

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

Кроме элиты MSSQL что-то нужно ещё лол?

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

нет. для типовых задач амно-сайтов - мускул на самом деле попроще.

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

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

Мне не нужно «часто проверять», мне нужно показать пользователю (оператору АРМ) обычный CRUD: списки заказов, пользователей, звонков в колл-центр и т.п. Естественно, мне нужно показывать сколько в системе тех же пользователей. Что тут не так-то?

Тормозить оно начинает уже от 100 тысяч записей, апгрейдом железа и покупкой provisioned IOPS на амазоне можно добиться относительно приемлимой работы на 500-800 тысячах, но в любом случае это неприемлемо. Сейчас у меня в проекте сущности, которых уже 40 миллионов, и их опять нужно показывать с поиском, фильтрацией и указанием количества результатов. Поиск и фильтрация по индексам работают идеально, а вот количество результатов считается минутами.

Я, конечно, прикостылил обёртывание запросов в SELECT COUNT(*) FROM ($query LIMIT 10000) и добавил парсер EXPLAIN ANALYZE, но не знаю как без матов прокомментировать такое «решение».

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

А зачем пользователю знать, сколько миллионов строк в результате? Показать кнопку «дальше» и всё. Как показать кнопку «дальше» и как эффективно найти следующую страничку, думаю, и так понятно.

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

Много хотите. Версионник не может хранить количество строк одно на всех, поэтому каждая сессия считает их для себя сама, и результат валиден только условно. Если же считать количество строк в таблице триггером, то одновременные транзакции, приводящие к изменению количества записей в таблице, будут ждать друг друга. Выбирайте, что вам подходит больше. За деталями - в вики. Собственно, блокировочник (типа mssql) считает (считывает из метаданных) быстро, но, в общем случае, тоже неправильно (см. уровни изоляции транзакций). В итоге задача решается подходящим для конкретной задачи способом, поэтому постгрес не дает ответа, но дает инструменты.

parihaaraka ()
Ответ на: комментарий от post-factum

MariaDB это то же самое, что и MySQL.

Лол.

назовешь 10 отличий и свободен

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

Тормозить оно начинает уже от 100 тысяч записей

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

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

Погоди, у тебя количество пользователей получается запросом select count(*) from tablename;?

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

Я, конечно, прикостылил обёртывание запросов в SELECT COUNT(*) FROM ($query LIMIT 10000) и добавил парсер EXPLAIN ANALYZE, но не знаю как без матов прокомментировать такое «решение».

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

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

есть документ со 100500 полями, который никогда не меняется, а для его визуализации нужна львиная доля данных. Что будет более «реляционно»: создавать кортеж размером 100500 или сделать отдельные поля для индексов, а остальное засунуть в блоб/композитный тип/JSON?

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

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

судя по подходу
если задача не решается влоб?

В тебе пропадает бюрократ, всеми силами цепляющийся за необходимость существования запретов там, где требуется простое как гвоздь решение, и считает само собой очевидным, что нужно набрать 10 справок на разных концах города. В лоб же не решается, нужен «подход»!

Не смешно ли, когда для подсчета количества результатов нужно потратить больше человеко-часов, чем для разработки всего проекта?

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

А зачем пользователю знать, сколько миллионов строк в результате?
Показать кнопку «дальше» и всё.

Зачем владельцу системы знать, сколько у него пользователей? Ну я даже не знаю. Может потому, что это основной маркетинговый показатель, на который он надрачивает?

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

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

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

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

бюрократ, всеми силами цепляющийся за необходимость существования запретов

Ну, тут как сказать. Есть такая бюрократия, польза которой очевидна. Но такие случаи относительно редки. Условно скажем, ядерная энергетика. Или в военной сфере. Есть нормативы, нарушение которых приводит к гибели людей. Такие нормы, понятно, будут соблюдаться пунктуально. В современных условиях значительная часть бюрократий легко идёт на нарушение таких норм, которые нарушать нельзя, даже законодательные нормы нарушаются. Выдумывая при этом свои собственные «низ-зя» для оправдания своего существования

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

Абсолютно насрать на транзакции.

Software development practices уровня ЛОРа.

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