
PostgreSQL *
Свободная объектно-реляционная СУБД
Расширение pg_variables
Расширение pg_variables
Часто при разрабоке прикладного ПО можно столкнуться с проблемой такого рода — для промежуточных данных требуется получить несколько результирующих наборов, например, для некоторых товаров надо иметь возможность получить их наличие в текущих заказах и сумму скидок, выданных для них ранее; или для некоторых пользователей получить список их друзей и сообщения этих пользователей в соцсетях и т.д и т.п.
Решение обычно выглядит вполне прямолинейным — сначала получаем список, скажем, пользователей, потом для них строим требуемый результирующий набор; потом опять получаем список пользователей и строим второй набор; и все бы хорошо, если бы построение такого списка не оказывалось бы достаточно затратной операцией — и, таким образом, если на основании этого списка надо построить несколько результатов, то получается, что этот список надо получить несколько раз со всеми сопутствующими накладными расходами. Очевидным решением этой проблемы кажутся временные таблицы, и это действительно так; к сожалению, с ними связан ряд не самых приятных особенностей — для каждой временной таблицы требуется создавать файл (а при уничтожении таблицы — удалять его). Кроме того, эти таблицы, разумеется, не видны для процессов автовакуума и, следовательно, не очищаются автоматически, и по ним не собирается статистика. Что еще хуже, при наличии длительных активных транзакций может происходить неограниченный рост системного каталога; более того, кеш операционной системы заполняется данными о созданных файлах для временных таблиц, что ведет к общей деградации производительности.
Следует также отметить, что так как имя таблицы должно быть известно при компиляции запроса, то использование разных таблиц может оказаться достаточно неуклюжим и заставляет прибегнуть к динамическому формированию запросов со всеми вытекающими последствиями; если же вспомнить, что plpgsql для динамических запросов не сохраняет план, то в случаях сложных запросов это может оказаться значительной проблемой.
PostgreSQL — не Rocket Science. Почем сейчас яйца?

Постоянно натыкаюсь на высказывания из серии «PostgreSQL слишком сложная база для моего небольшого проекта, поэтому буду продолжать работать с MySQL».
В этой статье я хотел бы показать, что человеку, знающему MySQL, не составит абсолютно никакого труда начать разрабатывать под PostgreSQL
Чем PostgreSQL лучше других SQL баз данных с открытым исходным кодом. Часть 2
В слогане PostgreSQL заявляется, что это «Самая продвинутая база данных с открытым исходным кодом в мире». В первой части этой серии мы рассмотрели хранение данных — модель, структуры, типы и ограничения по размеру, — чтобы дать вам несколько причин, почему Постгрес подтверждает свои слова делом. Во второй части мы поговорим о манипуляциях с данными и поиске, включая индексирование, виртуальных таблицах и возможностях запросов. В этой серии мы выясняем, что выгодно отличает PostgreSQL от других баз данных с открытым исходным кодом, а именно — от MySQL, MariaDB и Firebird.

DevConf::Storage — отдай голос за свою любимую базу данных до 31 мая


Представляем вашему вниманию 11 кандидатов на участие:
Крылья, ноги и хвосты: сильные стороны MySQL и когда PostgreSQL завоюет мир
Алексей Копытов
В наш гибридный век как разработчикам, так и администраторам часто приходится иметь дело со многими разными СУБД. Знание сильных и слабых сторон каждого продукта становится всё более важным навыком, но информация по этим вопросам, которую можно найти в сети, имеет целый ряд проблем: быстрая потеря актуальности в связи с постоянным и быстрым развитием популярных СУБД, разрозненность, а также предвзятость и зачастую некомпетентность авторов.
Мастер-мастер репликация в Tarantool
Konstantin Osipov
Расскажу как устроена и как пользоваться мастер-мастер репликацией в Tarantool:
- инициализация кластера
- добавление и удаление узлов
- разрешение конфликтов
- восстановление после аварии
- мониторинг состояния.
Postgres на китайском или настройка Full Text Search в Postgres для китайского языка

Обратился к нам клиент с просьбой обновить PostgreSQL до самой свежей версии, а заодно и научить его китайскому.
Точнее, оптимизировать процесс полнотекстового поиска на китайском, ибо тормозило все это дело нещадно.
Ниже описано как это нами было сделано.
Сразу перейдем к делу.
Использование Java массивов для вставки, получения и изменения PostgreSQL массивов
Чтобы продемонстрировать этот функционал, давайте создадим простую таблицу, которая хранит названия стран в одной колонке в виде текста, и список каких-то городов, принадлежащих этой стране во второй колонке в виде текстового массива.
CREATE TABLE city_example (
country TEXT,
cities TEXT[]
);
Теперь мы будем использовать JDBC интерфейс для добавления, получения и изменения данных в этой таблице.
Как найти ближайшее кафе, достопримечательность, свободное такси глазами программиста
PostgreSQL: Случай в вакууме
Один из наших клиентов, эксплуатирующий PostgreSQL под большой нагрузкой, столкнулся с проблемой, связанной с переполнением счетчика транзакций (xid wraparound), причем выхода из нее штатными средствами не существовало. Мы решили проблему с помощью хирургического вмешательства и выпустили патч, предотвращающий возникновение таких ситуаций в будущем.
В этой заметке мы расскажем, как и почему может произойти проблема и как ее не допустить.
Пять способов пагинации в Postgres, от базовых до диковинных
PostgreSQL в Azure. Часть 1
Этой статьей мы начинаем цикл заметок об использовании PostgreSQL в Microsoft Azure.
Первая статья будет об установке и настройке кластера PostgreSQL:
- Знакомство с ресурсами Azure
- Управление через azure cli
- Выбор подходящего хранилища
- Сборка классической связки ведущий-ведомый в одной группе доступности
Наследование таблиц в Postgresql с Ruby On Rails
Что это и зачем нужно?
Предположим у вас есть крупное новостное издание, у которого много разных типов материалов.
Для каждого типа материала существует своя модель: Topics::Article
, Topics::Online
, Topics::NewsItem
и так далее. У них будут одинаковыми большинство полей, такие как заголовок, обложка, текст, авторы. Различие только в нескольких специфичных полях, уникальных для каждого типа топика.
Поэтому вам не хочется раскладывать их по отдельным таблицам. Кроме нежелания создавать почти полностью повторяющиеся таблицы, для этого могут быть и несколько других причин. Необходимость сложных выборок с разными комбинациями этих типов, водопады UNION и полиморфизм подключающихся моделей в том числе.
Под катом опыт организации похожих моделей внутри Postgresql, с итогом в виде миграции на наследование таблиц. Стрельба в ногу серебряной пулей тоже присутствует, куда же без нее.
Восстановление данных PostgreSQL после потери pg_control
Для обеспечения отказоустойчивости СУБД PostgreSQL, как и многие базы данных, использует специальный журнал, в котором ведет историю изменения данных. Перед тем как записать данные в файлы БД, сервер PostgreSQL аккумулирует изменения в оперативной памяти и записывает в последовательный файл журнала, чтобы не потерять их из-за непредвиденного отключения питания.
Данные в журнал пишутся до того как пользователь базы данных получит сообщение об успешном применении изменений. Этот журнал называется журналом упреждающей записи (Write-Ahead Log или просто WAL), а файлы журнала хранятся в каталоге pg_xlog. Также периодически PostgreSQL сбрасывает измененные аккумулированные данные из оперативной памяти на диск. Этот процесс согласования данных называется контрольной точкой (checkpoint). Контрольная точка выполняется также при каждом штатном выключении PostgreSQL.
Информация о том, с какими внутренними значениями завершилась контрольная точка, хранится в файле global/pg_control и потому этот файл должен быть доступен СУБД еще до момента восстановления данных. Если PostgreSQL отключается нештатно, то изменения из файлов журнала (pg_xlog) применяются к файлам БД, начиная с позиции последней контрольной точки. Этот процесс называется восстановлением данных.
В файле pg_control находится информация:
- версия формата control-файла,
- контрольная сумма записанных в этот файл данных,
- версия формата файлов БД,
- уникальный идентификатор экземпляра БД,
- текущее состояние: работает/остановлен,
- позиция в журнале, соответствующая запущенной и предыдущей контрольным точкам,
- текущая ветвь времени (timeline),
- максимальный видимый номер транзакции (xid),
- максимальный номер внутреннего счетчика объектов (oid),
- время создания,
- и многое другое.
Посмотреть содержимое pg_control можно при помощи утилиты pg_controldata:
$ pg_controldata /var/lib/pgsql/9.5/data
pg_control version number: 942
Catalog version number: 201510051
Database system identifier: 6242923005164171508
Database cluster state: in production
pg_control last modified: Fri Apr 29 01:00:00 2016
Latest checkpoint location: EEAF/BAA5520
Prior checkpoint location: EEAF/BAA5440
...
Latest checkpoint's NextXID: 7/876524573
Latest checkpoint's NextOID: 264355612
Latest checkpoint's NextMultiXactId: 134512401
Latest checkpoint's NextMultiOffset: 547842659
...
Ближайшие события
О полезности индексов по выражениям
Чем PostgreSQL лучше других SQL баз данных с открытым исходным кодом. Часть 1
Возможно, вы спрашиваете себя: «Почему PostgreSQL?» Ведь есть и другие варианты реляционных баз данных с открытым исходным кодом (в рамках этой статьи мы рассматривали MySQL, MariaDB и Firebird), так что же Постгрес может предложить такого, чего нет у них? В слогане PostgreSQL заявляется, что это «Самая продвинутая база данных с открытым исходным кодом в мире». Мы приведем несколько причин, почему Постгрес делает такие заявления.
В первой части этой серии мы поговорим о хранении данных — модели, структуре, типах и ограничениях размера. А во второй части больше сфокусируемся на выборке и манипуляциях с данными.

Очередная Reflection Library и ORM для C++

Сразу же предупрежу о велосипедности выдаемого здесь на обозрение. Если прочтение заголовка вызывает лишь с трудом подавляемый возглас «Твою мать, только не новый
Мартовский Python Meetup: Python VS Erlang и возможности PostgreSQL
После долгого перерыва блудный Python Meetup снова с нами. На долгожданной мартовской встрече сообщества любителей и профессионалов языка программирования Python обсуждались животрепещущие темы: противостояние Python и Erlang, а также дополнительные возможности PostgreSQL.
Видеозаписи выступлений под катом. Приятного просмотра!

Управление структурой базы данных без боли

Хочу поделиться инструментом, который родился при разработке одного веб-проекта и очень помогает мне не потеряться в море таблиц, хранимых процедур, индексов и прочих обитателей базы данных.
Сам проект написан на Django, в качестве бекенда — PostgreSQL. В самом начале работы было решено, по крайней мере, частично отказаться от использования Django ORM в пользу «сырого» SQL и хранимых процедур. Другими словами, почти вся бизнес-логика вынесена на уровень базы данных. Сразу скажу, что готовить ORM я умею, но в данном случае требовалось производить многоступенчатые вычисления, связанные с множеством выборок, а это лучше делать на сервере БД и не таскать промежуточные данные в приложение.
Столкнувшись с необходимостью поддержания структуры базы данных вручную, без приятностей Django Migrations, я выяснил, что вручную писать инкрементальные SQL патчи возможно, но трудно уследить за зависимостями объектов БД. К примеру, когда функции, которая используется где-то еще, добавляешь еще один аргумент, простого CREATE OR REPLACE недостаточно — ее нужно сначала DROP, а потом CREATE. При этом нужно предварительно удалить зависимые от нее функции, а потом создать заново (а если от этих функций еще кто-то зависит, тогда надо и их пересоздать).
Под катом краткое описание возможностей в виде туториала. Встречайте — Sqlibrist.
Объясняя необъяснимое. Часть 5
В предыдущих постах этой серии я говорил о том, как читать вывод EXPLAIN и что означает каждая строка (операция/узел).
В заключительном посте я постараюсь объяснить, почему Постгрес выбирает «Операцию X», а не «Операцию Y».

Как определить каким файлам на диске соответствуют PostgreSQL таблицы
ERROR: could not read block 11857 of relation base/16396/3720450: read only 0 of 8192 bytes
Вклад авторов
Kilor 2578.3Igor_Le 1830.0erogov 1382.6varanio 753.8olegbunin 563.4chemtech 532.2badcasedaily1 500.0afiskon 496.0le0pard 425.0rdruzyagin 414.6