The Postgresmen Articles

PostgreSQL 8.4: Материалы для прессы

Wed, 1 Jul 2009 00:28:20 GMT

Официальный пресс-релиз

1 июля 2009 — Всемирная группа разработчиков PostgreSQL выпустила новую версию PostgreSQL, продолжая активную разработку самой развитой системы управления базами данных с открытым исходным кодом. Новая версия содержит множество улучшений, делающих администрирование, написание запросов и программирование баз данных PostgreSQL более простым, чем когда-либо. Благодаря 293 новым функциям и улучшениям, содержащимся в версии 8.4, причин выбрать PostgreSQL для вашего нового проекта стало ещё больше.

Львиная доля изменений в PostgreSQL 8.4 — это новые или улучшенные инструменты и команды для администрирования и мониторинга. Каждый пользователь может найти для себя те возможности, которые сделают именно его ежедневную работу с PostgreSQL более лёгкой и продуктивной.

«Мы используем PostgreSQL уже семь лет и с нетерпением ожидаем появления многих новшеств версии 8.4, в особенности таких возможностей как права доступа на столбцы, индивидуальные настройки локали у баз данных, поиск по частичному совпадению с помощью GIN-индексов и определяемые пользователем исключения, — говорит Джеффри Уэбстер (Jeffrey Webster), исполнительный директор проекта ZooLoo.com. — PostgreSQL дал нам возможность расти, не заставляя приносить в жертву целостность данных.»

Среди самых популярных улучшений можно выделить следующие.

Многопоточное восстановление базы данных, обеспечивающее до 8-кратного увеличения скорости реставрации базы данных из резервной копии.
Права доступа на столбцы, предоставляющие более тонкий контроль над важными данными.
Раздельные локали для баз данных, что упрощает работу с PostgreSQL в многоязычных окружениях.
Обновления «на месте» с помощью бета-версии инструмента pg_migrator, который позволяет перейти с версии 8.3 на 8.4 без существенного простоя системы.
Новые инструменты мониторинга запросов, помогающие администраторам получить лучшее представление об активности запросов.

В версии 8.4 стало проще анализировать данные с помощью развитых средств стандарта ISO/ANSI SQL2003: «оконных» функций (windowing functions), общих табличных выражений (common table expressions) и рекурсивных запросов с операциями соединения. «Такие структуры запросов существенно повышают выразительную мощь PostgreSQL-диалекта языка SQL, позволяя пользователям формулировать интересные запросы лишь в одном SQL-предложении, что ранее представлялось совершенно невозможным, — поясняет Сейлеш Кришнамёрфи (Sailesh Krishnamurthy), основатель компании Truviso. Улучшения хранимых процедур, такие как значения параметров по умолчанию и переменное число параметров (variadic parameters), делают программирование баз данных более простым, а код становится более компактным.»

С выходом новой версии также улучшается общая производительность приложений. Администратор баз данных Системы судопроизводства штата Висконсин Кевин Гриттнер (Kevin Grittner) отмечает: «PostgreSQL продолжает улучшать производительность с выходом очередной основной версии. Версия 8.4 включает несколько оптимизаций, таких как полусоединения (semi-joins) и антисоединения (anti-joins), что позволяет значительно сократить время обработки некоторых из наших наиболее важных запросов к базам данных.»

Появление новых возможностей означает, что PostgreSQL 8.4 будет служить большему числу пользователей, чем когда-либо. И среди таких новых пользователей — проект OpenStreetMap. «Когда мы планировали новую версию API для OpenStreetMap, стало очевидно, что нам нужна первоклассная система управления базами данных, которая не только предоставит все нужные нам возможности, но и будет хорошо работать на необходимых нам масштабах. Хотя существует много систем с открытым исходным кодом, выбор для нас очевиден, это PostgreSQL,» — говорит Том Хьюз (Tom Hughes), системный администратор проекта OpenStreetMap.

PostgreSQL давно и активно используется во многих российских компаниях. Вот как комментирует выпуск PostgreSQL 8.4 администратор баз данных социальной сети MirTesen.ru Сергей Коноплёв: «С выходом PostgreSQL 8.4 в первую очередь я планирую провести оптимизацию, направленную на использование GIN-индексов и contrib-модуля btree_gin. Это должно обеспечить существенных прирост скорости многих функций нашего проекта. Конечно же, поэкспериментирую с новыми настройками autovacuum и "картами видимости", посмотрю на статистику от pg_stat_statements и на CTE. И забуду о pgAdmin III, т.к. у меня теперь будет \ef в psql :-)»

Расширенный пресс-релиз

Список нововведений

Версия 8.4 оказалась рекордсменом по числу нововведений. Для удобства они были собраны в каталог на отдельных страницах:

Где скачать

Основная страница для загрузки со ссылками на инсталляторы и инструменты.
Исходный код
Инсталляторы для Windows
Инсталляторы для Linux и репозиторий пакетов
Пакеты для Solaris
Инсталляторы для Mac OSX
Порты для FreeBSD
Проект pg_migrator
Дополнительные компоненты
Сопутствующие и коммерческие программы

Документация

Документация в формате HTML и страницы с руководством устанавливаются вместе с PostgreSQL. Кроме того, вы можете скачивать, искать и комментировать подробную интерактивную онлайн-документацию.

Лицензия

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

Контакты

Web-страницы

Контакты

Россия
Николай Самохвалов
ru@postgresql.org
+7-905-783-9804
http://PostgreSQLRussia.org

Контакты в других регионах перечислены на странице контактов.

Полный текст цитат. Информация о цитируемых компаниях

«С выходом PostgreSQL 8.4 в первую очередь я планирую провести оптимизацию, направленную на использование GIN-индексов и contrib-модуля btree_gin. Это должно обеспечить существенных прирост скорости многих функций нашего проекта. Конечно же, поэкспериментирую с новыми настройками autovacuum и "картами видимости", посмотрю на статистику от pg_stat_statements и на CTE. И забуду о pgAdmin III, т.к. у меня теперь будет \ef в psql :-)» — комментирует появление новой версии Сергей Коноплёв, администратор баз данных социальной сети MirTesen.ru.
Контакты: email-адрес и основной сайт проекта МирТесен.

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

«Мы используем PostgreSQL уже семь лет и с нетерпением ожидаем появления многих новшеств версии 8.4, в особенности таких возможностей, как права доступа на столбцы, индивидуальные настройки локали у баз данных, поиск по частичному совпадению с помощью GIN-индексов и определяемые пользователем исключения, — говорит Джеффри Уэбстер (Jeffrey Webster), исполнительный директор проекта ZooLoo.com. — PostgreSQL позволяет нам расти, не заставляя приносить в жертву целостность данных.»
Вы можете связаться с представителем ZooLoo.com Мелиссой (Melissa) и посетить сайт ZooLoo.com.

«PostgreSQL продолжает улучшать производительность с выходом очередной основной версии, — заявил Кевин Гриттнер (Kevin Grittner), администратор баз данных, Система судопроизводства штата Висконсин. — Версия 8.4 включает несколько оптимизаций, таких как полусоединения (semi-joins) и антисоединения (anti-joins), что позволяет значительно сократить время обработки некоторых из наших наиболее важных запросов к базам данных.»
Вы можете связаться с Кевином Гриттнером и посетить сайт Системы судопроизводства штата Висконсин.

«Такие структуры запросов существенно повышают выразительную мощь PostgreSQL-диалекта языка SQL, позволяя пользователям формулировать интересные запросы лишь в одном SQL-предложении, что ранее представлялось совершенно невозможным,» — поясняет Сейлеш Кришнамёрфи (Sailesh Krishnamurthy), основатель и вице-президент по технологиям компании Truviso.
Контакты: email-адрес и сайт компании Truviso.

«Когда мы планировали новую версию API для OpenStreetMap, стало очевидно, что нам нужна первоклассная система управления базами данных, которая не только предоставит все нужные нам возможности, но и будет хорошо работать на необходимых нам масштабах. PostgreSQL позволяет нам сохранить и поддерживать целостность данных, используя внешние ключи и транзакционные операции обновления, и в то же время предоставляет нашим системным администраторам инструменты, необходимые для работы с нашей базой данных размером в 850 гигабайт, и позволяет управлять процессами непрерывного развития наших схем таблиц и операционными аспектами, такими как создание снапшотов базы данных. Хотя существует много систем с открытым исходным кодом, выбор для нас очевиден, это PostgreSQL,» — говорит Том Хьюз (Tom Hughes), системный администратор проекта OpenStreetMap.
Вы можете связаться с Томом Хьюзом и посетить сайт OpenStreetMap.

Корпоративная поддержка

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

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

Пожертвования также приветствуются.

Доклады о PostgreSQL на конференции Highload++ (октябрь 2008)

Mon, 27 Oct 2008 14:29:45 GMT

Конференция Highload++ собрала около 700 специалистов отрасли. PostgreSQL был представлен целой серией докладов, включая выступления зарубежных коллег, приехавших в Москву по приглашению компании «Постгресмен» и организаторов конференции.

Материалы выступлений разработчиков Skype представлены на отдельной странице: http://postgresqlrussia.org/articles/view/131.

О некоторых приёмах улучшения прозводительности приложений, использующих PostgreSQL, рассказал Николай Самохвалов, «Постгресмен»:

Highload++ 2008: Производительность PostgreSQL, Николай Самохвалов - Upload a Document to Scribd

Производительность PostgreSQL / Николай Самохвалов (Постгресмен)

Технический директор третьей по популярности социальной сети США myYearbook.com Гевин Рой большое внимание уделил этапам роста своего проекта, используемым технологиями и решениям, среди которых одну из ключевых ролей играют PostgreSQL-продукты:

Publish at Scribd or explore others: Computer Science Technology

Архитектура MyYearBook.com Масштабирование PostgreSQL: огонь и медные трубы/ Гевин Рой (MyYearBook) (англоязычный доклад)

Разработчики Skype в России. Материалы выступлений

Mon, 27 Oct 2008 14:05:47 GMT

В октябре 2008 года эксперты по базам данных компании Skype посетили Москву. За время своего визита Аско Оя (Asko Oja) и Марко Креэн (Marko Kreen) успели многое: сделали доклад на очередной встрече Российского сообщества пользователей PostgreSQL, выступили на конференции Highload++ и провели 4-часовой тренинг.

Здесь собранные материалы выступлений Аско и Марко. Основная тема всех выступлений — использование PostgreSQL для построения масштабируемой архитектуры высоконагруженного интернет-проекта. Разработчики Skype выпустили и продолжают активно развивать целую линейку продуктов, ориентированных на решение подобных задач: легковесный менеджер соединений PgBouncer, псевдоязык PL/Proxy, пакет инструментов для репликации и горячего резервирования SkyTools, систему для организации очереди PgQ.

Слайды выступления на октябрьской встрече PostgreSQL-сообщества:

Asko Oja talk at Russian PostgreSQL Community meeting, October 2008, Moscow - Upload a Document to Scribd

Слайды и видео выступления на конференции Highload++:

Moskva Architecture Highload

View SlideShare presentation or Upload your own.

Skype Distributed Database Architecture / Аско Оя (Skype)

Слайды тренинга, проведённого Аско Оя, Марко Креэн (Skype) и Иваном Золотухиным (Постгресмен):

Asko Oja Training Talk (Moscow, Russia, October 2008) - Upload a Document to Scribd

Слайды сентябрьской PostgreSQL-встречи: полнотекстовый поиск в PostgreSQL

Wed, 17 Sep 2008 19:18:31 GMT

16-го сентября 2008 года состоялась очередная, сентябрьская встреча Российского сообщества пользователей PostgreSQL.

Основная тема встречи: полнотекстовый поиск. Речь шла прежде всего о возможностях текущей реализации полнотекстового поиска в PostgreSQL версии 8.3.

Фёдор Сигаев и Иван Золотухин представили обширную демонстрацию возможностей и ответили на вопросы слушателей.

Слайды и скрипты демонстрации:

====================================
\d posts
SELECT count(*) FROM posts;
ALTER TABLE posts ADD COLUMN fts tsvector;
\d posts
UPDATE posts SET fts = to_tsvector('simple', msg_text);
VACUUM ANALYZE;

SELECT count(*) FROM posts WHERE fts @@ plainto_tsquery('simple', 'Мама раму');
CREATE INDEX gistidx ON posts USING gist (fts);
DROP INDEX gistidx; 
CREATE INDEX ginidx ON posts USING gin (fts);

SELECT count(*) FROM posts WHERE fts @@ plainto_tsquery('simple', 'Мама рама');


DROP INDEX ginidx;


\dF
\dF+
SELECT to_tsvector('russian', 'Мама мыла раму');
SELECT plainto_tsquery('russian', 'Мама мыла раму');


UPDATE posts SET fts = to_tsvector('russian', msg_text);
SELECT count(*) FROM posts WHERE fts @@ plainto_tsquery('russian', 'Мама рама');


SELECT to_tsvector('russian', 'валил валившийся вал');
SELECT to_tsvector('russian', 'вокзал в вокзале');
SELECT to_tsvector('russian', 'батарея батарею');

CREATE TEXT SEARCH DICTIONARY ru_ispell (
    TEMPLATE = ispell,
	DictFile = ru_RU,
	AffFile = ru_RU,
	StopWords = russian
);

 ALTER TEXT SEARCH CONFIGURATION ru
	ALTER MAPPING FOR hword, hword_part, word 
	WITH ru_ispell, russian_stem;

SELECT to_tsvector('ru', 'валил валившийся вал');
SELECT to_tsvector('ru', 'вокзал в вокзале');
SELECT to_tsvector('ru', 'батарея батарею');
SELECT to_tsvector('ru', 'незастолбленное слово');

UPDATE posts SET fts = to_tsvector('ru', msg_text);
VACUUM ANALYZE;
CREATE INDEX ginidx ON posts USING gin (fts);


SELECT * FROM ts_debug('ru', 'Мама мыла агромедную раму в room');
SELECT ts_lexize('ru_ispell', 'туши');
ELECT * FROM ts_parse('default', '123 - a number');

SELECT id, ts_rank_cd(fts, q) AS r 
	FROM posts, plainto_tsquery('ru', 'Москва') AS q  
	WHERE fts @@ q ORDER BY r DESC LIMIT 10;

SELECT id, ts_rank_cd(fts, q) AS r 
	FROM posts, plainto_tsquery('ru', 'Москва Питер') AS q  
	WHERE fts @@ q ORDER BY r DESC LIMIT 10;
SELECT id, ts_rank(fts, q) AS r 
	FROM posts, plainto_tsquery('ru', 'Москва Питер') AS q  
	WHERE fts @@ q ORDER BY r DESC LIMIT 10;

SELECT id, ts_headline('ru', msg_text, q) , ts_rank_cd(fts, q) AS r 
	FROM posts, plainto_tsquery('ru', 'Москва Питер') AS q  
	WHERE fts @@ q ORDER BY r DESC LIMIT 10;

SELECT id, ts_headline('ru', msg_text, q), r FROM
	( SELECT *, ts_rank_cd(fts, q) AS r
		FROM posts, plainto_tsquery('ru', 'Москва Питер') AS q
		WHERE fts @@ q ORDER BY r DESC LIMIT 10
	) AS res;

 SELECT * FROM ts_stat('SELECT fts FROM posts') ORDER BY ndoc DESC;
 SELECT * FROM ts_stat('SELECT fts FROM posts ORDER BY id LIMIT 1000') ORDER BY ndoc DESC LIMIT 20;

В завершение встречи Олег Бартунов рассказал о планах по развитию подсистемы полнотекстового поиска, о том, что планируется к выходу в 8.4 и даже о том, что будет после 8.4:

Онлайн-встреча с ведущими экспертами PostgreSQL, 30 июня 2008

Thu, 31 Jul 2008 03:05:44 GMT

30 июня компания «Постгресмен» провела онлайн-сессию «Вопросы к ведущим мировым экспертам PostgreSQL». В течение трёх часов любой желающий мог задать вопрос одному из приглашённых гостей и получить исчерпывающий ответ. В результате было получено более 40 вопросов, ни один из которых не остался без внимания.

Участники сессии:

Брюс Момджан (Bruce Momjian), координатор разработки PostgreSQL, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB.
Максим Богук, ведущий администратор баз данных компаний Rambler и Мастерхост, известный специалист по PostgreSQL.
Фёдор Сигаев, разработчик подсистемы полнотекстового поиска, систем индексации GiST, GIN и множества дополнительных модулей, один из основных членов PostgreSQL Global Development Group.
Марко Креэн (Marko Kreen), один из основных архитекторов баз данных компании Skype, разработчик и мантейнер таких проектов как PL/Proxy, Skytools, PgBouncer и pgcrypto.

Вопрос №1

Сергей Коноплёв:
Вопросы к Марко Креэн:
1) Когда планируется реализовать механизм контекста ошибок (errcontext mechanism) в plpython?
2) Мы используем try-except-print-traceback решение для упрощения поиска мест ошибок в plpyhton процедурах, есть ли более эффективный способ?

Марко Креэн, инженер компании Skype:
1) Я не являюсь активным разработчиком PL/Python, лучше всего об этом может рассказать Ханну Кросинг (Hannu Krosing), который сейчас поддерживает этот проект.
2) Если Вы говорите об ошибках Python, тогда да, действительно, механизмы работы с исключениями должны быть улучшены, чтобы предоставлять больше подробностей об ошибке. Если имеются в виду SQL-ошибки, в их обработке существуют довольно большие проблемы, и я не знаю, имеет ли Ханну какие-либо планы по их устранению. В настоящий момент лучше пытайтесь обойтись без их отлова.

Вопрос №2

kai:
Появится ли когда нибудь официальный русскоязычный ресурс по Postgres с русской документацией, обсуждениями и русскоязычным сообществом? Ведь продукт сложный, обладает большим функционалом и кучей дополнительных модулей. Подчас сложно бывает разобраться со всем этим обладая только англоязычной документацией и общаясь с англоязычным коммунити. (Однако при установке новой версии при прочтении соглашения ведется ссылка на русский док, а там перенаправление на «как обычно».)

Максим Богук, администратор баз данных компаний Рамблер и Мастерхост:
В русскоязычном списке рассылки http://archives.postgresql.org/pgsql-ru-general/ Вам всегда ответят на все Ваши вопросы. Также достаточно большая активность есть на форуме http://www.sql.ru/forum/actualtopics.aspx?bid=7. Дополнительно, обратите внимание на ресурс «Постгресмена» (компании-организатора этой конференции), разделы «Новости» и «Cтатьи».

Вопрос №3

kai:
Одна из досадных штук в работе — это отсутствие конструкции "INSERT OR UPDATE". В MySQL можно сделать так: "INSERT INTO users (username, email) VALUES ('Jo', 'jo@email.com') ON DUPLICATE KEY UPDATE email = 'jo@email.com'". Появится ли что-нибудь похожее в PostgreSQL?

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Стандартный (ANSI) способ для таких вещей — это MERGE или UPSERT. Оба способа находятся у нас в TODO-листе и, насколько я знаю, кто-то работает над этой функциональностью для PostgreSQL 8.4, хотя лично я ещё не видел этого патча. Мы, вне всяких сомнений, нуждаемся в таком синтаксисе.

Вопрос №4

kai:
Будет ли улучшена работа с обработкой данных на различных языках? Например, у меня многоязычный сайт, и я был бы рад получать для него форматированные из timestamp даты в зависимости от указанной в SQL запросе локали.

Фёдор Сигаев, ведущий разработчик PostgreSQL:
Работа над этим ведётся, но в основном она сосредоточена в области COLLATION и полнотекстового поиска. Первое, с чем надо разобраться — это хотя бы создание базы с локaлью, отличной от локали кластера. А формирование даты обычно намного проще и гибче делается в приложении.

Вопрос №5

Alexander:
Вопросы к разработчикам Skype:
1) Хочется оценить масштабы Skype, хотя бы приблизительно. Сколько пользователей сейчас зарегистрировано? Сколько пользователей находятся одновременно онлайн? Сколько транзакций в секунду выполняет Ваш PostgreSQL? Сколько у Вас серверов PostgreSQL?
2) Как правильно померить количество транзакций в секунду в PostgreSQL?

Марко Креэн, инженер компании Skype:
1) Общее количество пользователей у нас сейчас в районе 300 миллионов. Я точно не знаю насчёт активных пользователей, но мой Skype-клиент показывает, что сейчас онлайн находятся 10 миллионов пользователей, и это далеко не пиковая нагрузка. У меня нет точных цифр по количеству транзакций в секунду (TPS), но, кажется, наша нагрузка — где-то в районе 10-20 тысяч TPS. Всего у нас более 100 серверов PostgreSQL, хотя и не все из них работают одновременно.
2) Используйте анализатор логов или pgBouncer, установленный перед базой данных, он даёт такую статистику.

Вопрос №6

Сергей Коноплёв:
Планируется ли реализация механизмов для повышения производительности OLAP-функционала? Если да, то где можно найти информацию об этом?

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Не могли бы Вы уточнить, какая OLAP-функциональность Вам необходима? У нас в TODO-листе есть windowing-функции, и кто-то работает над ними для 8.4. У нас также уже есть WITH RECURSIVE патч для PostgreSQL 8.4.

Сергей Коноплёв:
Спасибо за ответ. Имелись ввиду внутренние механизмы, улучшающие производительность.

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Мне кажется, Вы имеете в виду фунциональность CUBE. Вы пробовали contrib/cube?

Сергей Коноплёв:
Да, я имел ввиду работу с гиперкубами, насколько я могу судить по названию контриба. Нет, contrib/cube не пробовал, а где страница этого проекта? Я не могу её найти. Не знаю, возможно я перемудриваю, но по-моему было бы полезно реализовать ondisk-гиперкубы в ядре. Насколько я понимаю, это должно представлять собой авто-пополняемую таблицу с индексами по перестановкам всех полей.

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Contrib/cube является частью дистрибутива исходных кодов PostgreSQL.

Вопрос №7

Сергей Коноплёв:
У нас есть задачи генерации событий на основе операций в БД: добавление/изменение/удаление. Это, конечно, можно делать в триггерах, но на уровне WAL файлов IMHO это было бы эффективнее, не говоря о том, что обработку можно было бы делать отложенной и вынесенной. Вопрос - есть ли хорошо документированный API для работы с WAL файлами и, если есть, насколько сильно он будет меняться от версии к версии? Если да, то где можно найти информацию об этом?

Фёдор Сигаев, ведущий разработчик PostgreSQL:
Внешнее API отсутствует, поскольку никогда не предполагался внешний доступ к WAL-файлам. Более того, их формат совместим только для минорных версий, гарантии совместимости форматов между major-версиями никогда даже не предполагалось. В Постгресе даже нет центрального расшифровщика WAL-записей, каждая запись в некотором смысле контейнер, который имеет признак расшифровщика (таблица, btree-индекс, GiST-индекс и т.д.) Строить свою обработку на WAL-логах не очень удобно ещё и по следующей причине: файлы могут использоваться повторно, и Постгрес никак не оповещает внешний мир об этом.

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
То есть, Вы ищете способ чтения WAL-файлов напрямую? Не существует никакого API для этого, так как их внутренний формат достаточно сложен. Я сейчас понял, что возможность чтения логов могла бы быть полезной, возможно, нам стоит рассмотреть вопрос о включении этого пожелания в TODO-лист. У нас есть на самом деле pg_filedump (http://sources.redhat.com/rhdb/utilities.html), но я не уверен, что он дампит WAL-файлы.

Марко Креэн, инженер компании Skype:
Может быть, это более эффективно, но менее надёжно (например, WAL-файл может сротироваться без вашего ведома). Пожалуйста, попробуйте PgQ из пакета Skytools и поизучайте скрипты, которые используют этот механизм для организации очереди. Это очень эффективная очередь внутри базы данных, легкая в использовании и надёжная. Также в ней существуют встроенный фреймворк для того, чтобы гарантировать транзакции между несколькими базами данных при обработке очереди. Ещё в ней существуют триггеры, которые автоматически определяют структуру таблиц и форматируют данные в легко разбираемом формате (urlencode).

Вопрос №8

sakalr:
Вопрос по поводу книг. Сегодня мне пришла книга из британского Амазона, пришлось ждать несколько недель. В России из актуальных версий нашёл только книгу за 3900 рублей. В общем, пусть книги будут даже на английском, но я хочу прийти в «Библио-Глобус» или в «Молодую Гвардию» и увидеть эту книгу на полке, но не за 3900 рублей (на Амазоне эта же книга была в 2 раза дешевле). Есть потребность в разработке на PostgreSQL, но для меня, как для новичка в PgSQL, это сложно. Постоянно приходится общаться на freenode на ломаном английском, осваивать азы, потратив много времени, когда это должно быть просто механическим усвоением. Именно поэтому возникает вопрос про книги. Книги по postgresql (англ./рус.) очень нужны.

Фёдор Сигаев, ведущий разработчик PostgreSQL:
Если Вы уже знакомы с каким-либо диалектом SQL, то работа в Постгресе не должна причинять Вам большие неудобства. Документация в Постгресе очень хороша и ее обычно хватает (при внимательном чтении, конечно). Если Вы не знакомы с SQL, то лучше взять любой учебник по SQL.

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Я полностью согласен с тем, что нужно больше английских и русских книг. В идеале, нам нужно иметь переведённую на русский язык документацию по PostgreSQL.

Вопрос №9

yar-tour:
Здравствуйте! Интересует вопрос про поддержку COLLATION и поддержку установки триггеров на отдельные поля таблицы. Спасибо.

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Ух, мы еще не релизовали механизм COLLATION, но кое-кто уже работает над реализацией поддержки локалей (locales) на уровне баз данных для PostgreSQL 8.4. Колоночные триггеры занесены в наш список TODO, но мне не известно, работает ли кто-нибудь над этим в настоящее время.

Фёдор Сигаев, ведущий разработчик PostgreSQL:
COLLATION — насколько я помню, такие работы ведутся в 8.4, но пока этот патч не до конца прошёл процедуру принятия. Триггер на поле таблицы отсутствует, и пока его появление не предвидится. Его эмуляция легко строится на основе обычных триггеров: триггерная функция имеет доступ и к старой, и к новой версии записи.

Вопрос №10

alexanderfess:
Здравствуйте! Интересует, есть ли в области Postgres что-то мощнее pgAdmin или phpPgAdmin для разработчика БД. ИМХО они довольно слабые. Планируются ли какие-нибудь проекты в данной области?

Фёдор Сигаев, ведущий разработчик PostgreSQL:
Не знаю, я ими не пользуюсь. Да и сам Постгрес не включает себя графического клиента.

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Я не знаю более мощных утилит, кроме, возможно, коммерческих продуктов Navicat или EMS SQL Manager. Я никогда не пользовался такими средствами (http://www.freshee.info/program.php?id=31408).

Вопрос №11

Михаил Дружинин:
Здравствуйте. К вопросу про генерацию событий на основе операций в БД: добавление/изменение/удаление. Есть ли возможность сделать обработку отложенной/асинхронной? Чтобы результат обработки не мог повлиять на транзакцию и не замедлял ход её выполнения.

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Обычно в этом случае разработчики добавляют изменения в таблицу и обрабатывают их большими пачками позднее.

Марко Креэн, инженер компании Skype:
Попробуйте Skytools. Они содержат модуль для создания обобщенной очереди (PgQ) и простые в использовании триггеры для вставки событий в эту очередь. Skytools также содержит фреймворк для обработки очереди на языке Python, хотя Вы можете это сделать и на любом другом языке. Чтобы прочитать событие из очереди, достаточно пары вызовов SQL-функций.

Фёдор Сигаев, ведущий разработчик PostgreSQL:
Триггер по определению обязан отработать в транзакции, поэтому чисто триггерное решение отложенной обработки невозможно. Первое, что напрашивается, — это складывание триггером событий в таблицу или использование механизма LISTEN/NOTIFY. Кстати, в PostgreSQL 8.4 ожидаются улучшения этого механизма: будет возможно добавить строковый параметр к NOTIFY-событию.

Максим Богук, администратор баз данных компаний Рамблер и Мастерхост:
Чтобы результат обработки не мог повлиять на транзакцию и не замедлял ход её выполнения, проще всего скидывать триггером задания на обработку в отдельную таблицу и уже далее асинхронно обрабатывать задания внешним процессом + возможно использовать LISTEN/NOTIFY для уведомления процесса-обработчика о появлении нового задания в очереди.

Вопрос №12

Артем Ходлевский:
Здравствуйте. У меня вопрос такой: могут ли эксперты порекомендовать способ поддержки значительного количества систем, в условиях довольно интенсивной разработки? Код весь находится в SVN-репозитории, а для обновления существующих систем приходится делать большое количество ручной/рутинной работы.
Если нужно, могу уточнить вопрос:
Есть базы данных, уже установленные и работающие, их количество более десяти. Но в процессе дальнейшей разработки структура меняется (добавляются поля, добавляются/модифицируются хранимые процедуры), эти изменения попадают в инициализационный SQL-сценарий (хранится в SVN). Как сделать удобным (возможно, полуавтоматическим) применение этих изменений ко всем системам, то есть, апгрейд существующих БД? Мы частично решили эту проблему — ведём параллельный SQL-сценарий, который содержит команды, которые выполняют изменения (ALTER / CREATE OR REPLACE), но его поддержка требует от разработчиков очень большого внимания, а малейшие ошибки потом приводят к конфликтам или сбоям.

Фёдор Сигаев, ведущий разработчик PostgreSQL:
Да, это «больной вопрос». Для автоматизации могу только посоветовать http://apgdiff.sourceforge.net/.

Артем Ходлевский:
Спасибо за ответ, как-то мы не очень искали сторонние инструменты, думали для этого есть штатный способ. Будем пробовать.

Вопрос №13

algo:
Когда STATEMENT TRIGGER получат доступ к записям?

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Я слышал о том, что кто-то работает над тем, чтобы STATEMENT TRIGGER мог получать доступ к записям. Точно не знаю, какое именно API мы должны сделать для этого.

Вопрос №14

yar-tour:
Вопрос всем и особенно Брюсу, которого я очень рад встретить: каким вы видите развитие PostgreSQL на ближайшие пару лет?

Марко Креэн, инженер компании Skype:
Я предполагаю рост, конечно. Следующие два года имеют один интересный аспект: PostgreSQL имеет шанс заменить MySQL как самую популярную систему управления базами данных с открытым кодом. Но сможем ли мы сделать это? Саморазрушения MySQL, которое происходит в настоящее время, будет недостаточно, нам самим потребуется решить несколько важных проблем — в частности, создать лёгкую в использовании репликацию, лёгкий при построении кластер, встроенную систему апгрейдов. Всё это сделало бы PostgreSQL более удобным для большего количества пользователей.

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Это, кстати, тема моей последней презентации, «Путь PostgreSQL в будущее» (http://momjian.us/main/writings/pgsql/future_path.pdf). Мне кажется, что Постгрес двигается к тому, чтобы занять лидирующее место в индустрии систем управления базами данных. Всё свидетельствует об этом — активная разработка, компании, которые используют Постгрес, пресса, мнения людей и т. д. Я только что был на конференции OSCON, и там интерес к Постгресу был просто невероятен. Может быть, у Вас есть какие-нибудь вопросы по моему PDF?

yar-tour:
Не могли бы Вы назвать несколько больших компаний, которые начали интересоваться PostgreSQL в последнее время? Также интересно услышать про приложения сторонних разработчиков.

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Конечно, у нас есть крупные пользователи почти во всех сегментах индустрии. Это технология, производство, правительственные учреждения, розничная торговля, сервисные компании, финансовые учреждения. Например, на конференции OSCON на прошлой неделе оказалось, что глава всего IT-направления компании Google любит Постгрес, хоть в Google и используют MySQL. Он взял футболку с Постгресом и будет носить ее в офисах Google. Кажется, сегодня уже каждый слышал про Постгрес — совсем не так дело обстояло всего несколько лет назад, когда мы были почти неизвестны. Мы нравимся даже разработчикам MySQL.

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

Вопрос №15

algo:
Уважаемые разработчики, а хранимые битмап-индексы когда планируются?

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Кто-то их уже реализовывал, но тогда возникла проблема с тем, как vacuum будет чистить такие индексы, ведь это индексы с потерями (lossy).

Фёдор Сигаев, ведущий разработчик PostgreSQL:
Разработчик этого патча вроде бы потерял интерес к нему в первую очередь из-за нерешённой проблемы автоматического вычисления длины bitmap и возможного полного перестроения индекса. Воoбще говоря, on-disk bitmap индекс имеет очень ограниченную область применения и очень плохо автоматизируется (если Вы его используете, значит, Вы должны очень хорошо подумать).

Марко Креэн, инженер компании Skype:
Существует патч для этого. Вы можете посмотреть в архивах рассылки или спросить разработчиков о его состоянии.

Вопрос №16

Юрий Леонович Русинов:
Здравствуйте! Я разрабатываю подсистему поиска в базе геоданных на основе связки PostgreSQL + PostGIS. Хотелось бы запускать поиск на сервере БД в виде отдельного потока, насколько это возможно?

Фёдор Сигаев, ведущий разработчик PostgreSQL:
Не понял. Что значит — отдельного потока? Постгрес сам по себе не умеет использовать больше одного потока (на самом деле — процесса) для обработки одного SQL-запроса. Видимо, Вас может удовлетворить использование нескольких соединений к Постгресу.

Вопрос №17

yar-tour:
Это баг или фича, что AFTER-триггер может прерваться, например, из-за ошибки в процедуре, и записи при этом не добавятся? В случае с BEFORE-триггером это логично, а вот мне кажется, что AFTER-триггер должен работать только после добавления записи в таблицу, это как бы вытекает из его названия.

Максим Богук, администратор баз данных компаний Рамблер и Мастерхост:
Это вполне логичная фича. Так как даже AFTER-триггер выполняется внутри транзакции (даже если включен автокоммит, это только значит, что любая команда будет формально в BEGIN; COMMIT; завернута). Поэтому ошибка в AFTER-триггере, как и любая вообще ошибка внутри транзакции, будет вызывать откат транзакции (ROLLBACK). И запись, даже уже внесенная в таблицу, на самом деле не появится.

yar-tour:
Извините, тогда я не очень понимаю различия между AFTER- и BEFORE-триггерами...

Максим Богук, администратор баз данных компаний Рамблер и Мастерхост:
Например, если у таблицы есть serial поле или default поле, то при вставке BEFORE-триггер не увидит значения этих полей. А AFTER-триггер уже видит новую запись полностью, включая default поля (и изменения возможно внесенные BEFORE-триггерами). Фактически, BEFORE-триггер работает со значениями, пришедшими от запроса, а AFTER-триггер работает со значениями, реально записанными в базу (а это не одно и то же).

Вопрос №18

kai:
Вот ещё вопросик, про pgAdmin - планируется ли регулярно собирать пакеты под распространенные версии Linux? Например, в Ubuntu 8.04 сейчас pgAdmin 1.8.2 (глючит), а на сайте pgadmin.org уже лежит pgAdmin 1.8.4.

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Мне сказали, что эти проблемы были исправлены в Убунту (Ubuntu), которым, кстати, я сам пользуюсь. Я думаю, единственной проблемой здесь является заставить разработчиков Убунту обновить сервера для апдейтов. Также отлично работает связка пакетов программного обеспечения с Постгресом для Убунту и, возможно, Вам стóит её попробовать. Там есть PostgreSQL-сервер, pgAdmin и много другого ПО в пакетах, подготовленных Дейвом Пейджем (Dave Page), автором pgAdmin, а не разработчиками Убунту.

Вопрос №19

alrond:
1) Хотелось бы более детальных рекомендаций по тюнингу производительности, а то везде только о shared_buffers написано (чем больше, тем лучше :), все остальное расплывчато.
2) Как насчет обновления базы с версии на версию без необходимости в создании дампа, чтобы не было простоев в работе, если система не кластерная. Может, такое есть и я просто еще не знаю. Имеется в виду смена мажорной версии.

Максим Богук, администратор баз данных компаний Рамблер и Мастерхост:
1) Все остальные параметры помимо shared_buffers очень сильно зависят от типа нагрузки на Вашу базу. И единого оптимального решения там нет (иначе бы оно уже давно попало в базовый конфиг). Полное руководство по тюнингу Postgres будет представлять из себя хороший такой том килограмм на 5 (лежит у меня дома один такой по Oracle). Полезность его при отсуствии большого опыта достаточно небольшая, а ресурсов на написание и обновление при выходе новых версий будет уходить много. Опыт + понимание принципов + документация на сайте, как правило, достаточны для решения большинства задач тюнинга.
2) Ведутся работы по написанию встроенной upgrade-системы. Но пока она явно не готова. Как промежуточное, но вполне рабочее решение для миграции рекомендуется использовать Slony-I (и эта схема вполне работает, даже для очень больших баз). У нас есть положительный опыт активного использования этого метода для подобных задач в Rambler.

Фёдор Сигаев, ведущий разработчик PostgreSQL:
1) По опыту, люди очень часто забывают менять параметр effective_cache_size и work_mem — они оба очень важны для планировщика/оптимизатора запросов, а второй еще оказывает значительное влияние на время выполнения запроса.
2) Поддержите работу Зденека Коталы (Zdenek Kotala) — это его проект. Там есть очень много сложностей связанных с layout-ом дисковых страниц.

Марко Креэн, инженер компании Skype:
1) Вики на основном сайте Постгреса содержит секцию про настройку производительности: http://wiki.postgresql.org/wiki/Main_Page.
Несколько дополнительных замечаний на основе моего опыта:
* По крайней мере на OLTP-базах большие shared_buffers не являются чем-то необходимым, они просто съедают кэш операционной системы (по крайней мере в Linux).
* Все хотят править postgresql.conf и знают, что нужно сделать, чтобы улучшить производительность, но есть несколько вещей, о которых обязательно стóит помнить (опять же, речь об OLTP-нагрузках):
   - Используйте короткие транзакции. Открытые транзакции потребляют ресурсы и открывают много блокировок.
   - Чем меньше запросов входит в транзакцию, тем лучше. В идеале — это единственный запрос в autocommit-режиме, который вызывает функцию, содержащую всю логику транзакции. При использовании PL/pgSQL это автоматически приводит к кэшированию планов запросов.
   - Используйте небольшое число работающих процессов сервера PostgreSQL (PostgreSQL backends). Каждый запущенный процесс PostgreSQL потребляет ресурсы, даже если он не выполняет транзакций. Это значит, что Вам следует использовать хороший менеджер соединений. Я слышал, что у Java-разработчиков есть собственные решения для этого, во всех остальных случаях я рекомендую pgBouncer.
2) Если действительно хотите минимизировать время простоя, тогда встроенная возможность апгрейда вам не поможет. Единственное по-настоящему работающее решение — реплицировать всю базу данных на другую машину и затем переключить их роли. Может быть сделано с помощью Slony-I или Skytools.

Вопрос №20

kai:
У меня лично есть проблема с распространением изменённых схем между серверами. При удаленной работе у каждого разработчика стоит своя копия БД, собственно если один добавляет новое поле в таблицу, то это нужно сделать всем. И это довольно таки сложно организовать. Посему родился вопрос, не собираются ли разработчики PG расширить инструментарий полезной утилиткой diff для схем БД, что бы к примеру можно было сравнить схему БД из .sql файла и существующей БД? Конечно, такой функционал, как в http://www.sqlmanager.net/en/products/mysql/dbcomparer не нужен, но просмотреть разницу между схемами было бы очень удобно.

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Нет, боюсь, подобный продукт всегда будет сторонним, не входящим в основной дистрибутив.

Фёдор Сигаев, ведущий разработчик PostgreSQL:
Эти задачи как раз и решает (как минимум должен) http://apgdiff.sourceforge.net/.

Вопрос №21

algo:
Eсть много приложений, написанных на MySQL, портировать которые на PG «одним движением пальца» мешает отсутствие в последнем нескольких простых «syntax sugar» фич типа: REPLACE, ON DUPLICATE KEY UPDATE. Планируются ли дальнейшие шаги в этой области? Практическая реализация представляется несложной, а увеличение области применения — значительное. Имеется в виду не принципиальная возможность реализации таких операций, а непосредственно синтаксис.

Максим Богук, администратор баз данных компаний Рамблер и Мастерхост:
Вряд ли кто будет делать такие вещи специально совместимыми по синтаксису с MySQL... Функциональность REPLACE/ON DUPLICATE KEY UPDATE сейчас в работе и скорее всего будет включена в релиз 8.4. Но синтаксис скорее всего будет ANSI, а не MySQL. (Как правило, пройтись глобальным поиском и заменить конструкции на совместимые с PostgreSQL не так сложно, как кажется.)

Фёдор Сигаев, ведущий разработчик PostgreSQL:
Здесь позиция сообщества разработчиков такова: максимально пытаться соответствоать существующему стандарту SQL и не пытаться делать свой синтаксис или повторять чей-то ещё. Именно по этой причине отказались от патча CONNECT BY в пользу WITH RECURSIVE.

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Вряд ли мы будем поддерживать точный MySQL-синтаксис для REPLACE. Сейчас это стало ANSI-стандартом, а если мы будем поддерживать MySQL-синтаксис [и их gotchas], наш собственный станет слишком сложным.

Вопрос №22

kai:
И ещё один вопрос, по поводу драйверов. Можно ли как-нибудь форсировать разработку драйвера для perl (DBD::Pg)? Основная проблема - PostgreSQL поддерживает различные типы данных, включая массивы и хеши, а драйвер - нет. Хоть поддержка массивов появилась в новой версии драйвера, но, на сколько я знаю, за последний год ни один распространенный Linux-дистрибутив не включил в себя обновлённую версию этого драйвера.

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Так дело лишь в задержке в обновлении Linux-дистрибутива продукта Perl::DBD. Я бы поинтересовался у производителей дистрибутива. Обычно, когда люди задают производителям дистрибутивов подобные вопросы, они выпускают обновления быстро.

Максим Богук, администратор баз данных компаний Рамблер и Мастерхост:
За последний год DBD::Pg был фактически переписан с нуля и появилась поддержка многих приятных вещей. И насколько я вижу, DBD::Pg продолжает активно развиваться (по сравнению с тем, что было 2 и более лет назад). Вопрос обновления DBD::Pg в Linux дистрибутивах лучше задавать тем, кто поддерживает эти дистрибутивы (но насколько я знаю, многие Linux-дистибутивы крайне консервативны в обновлении подобных вещей). В крайнем случае всегда можно собрать руками мимо системы портов/пакетов.

Вопрос №23

Юрий Леонович Русинов:
Федору Сигаеву: если на сервере есть хранимая процедура на C/C++, то могу ли я в ней создать дочерний поток и выполнить в нём какие-либо операции?

Фёдор Сигаев, ведущий разработчик PostgreSQL:
Можете, но смотря что за операции. Ни одна внутренняя функция Постгреса не разрабатывалась с оглядкой на thread-safe. Так что в отдельном потоке Вам предстоит самостоятельно заботиться обо всём, включая аварийное завершение этого потока.

Вопрос №24

Михаил Дружинин:
Спасибо за ответ на мой предыдущий вопрос. Собственно, решение с таблицей для заданий пришло и мне. Только функция-обработчик этих заданий с увеличением их количества тоже будет усложняться.
Попутно вспомнилось ещё два вопроса:
1) Есть ли для PostgreSQL модуль, реализующий выполнение задач по расписанию.
2) Можно ли вызвать функцию, возвращающую что-то отличное от void, по его строковому имени 'my_func_1' и, соответственно, получить возвращаемое ей значение.

Фёдор Сигаев, ведущий разработчик PostgreSQL:
1) Не слышал и сомневаюсь, что такой есть. В Постгресе просто нет такого «хука».
2) Можно, конечно, но я не понял вопроса — это вопрос по С, PL/pgSQL или SQL? в первом случае — man dlopen, во втором и третьем — EXECUTE (http://www.postgresql.org/docs/8.3/static/plpgsql-statements.html#PLPGSQL-STATEMENTS-EXECUTING-DYN)

Максим Богук, администратор баз данных компаний Рамблер и Мастерхост:
1) Разработчики pgAdmin сделали вот такую вот вещь для Ваших задач: http://www.pgadmin.org/docs/1.4/pgagent.html. При использовании pgAdmin штука достаточно удобная. Но в production я его не использовал ни разу. Мне штатного крона хватает.

Вопрос №25

Будет ли Skype открывать исходный код каких-либо новых PostgreSQL-проектов? Также интересует их опыт по использованию PL/Proxy и Skytools.

Марко Креэн, инженер компании Skype:
Первая часть вопроса: да, есть планы по открытию кода нашего фреймворка по мониторингу/управлению [PostgreSQL-серверами]. Но он все еще находится в разработке, поэтому я не могу назвать точную дату релиза.
Вторая часть: также есть идея опубликовать небольшой пример базы данных «в стиле Skype», в которой будут увязаны все наши компоненты одновременно — PL/Proxy, PgBouncer, PgQ и различные варианты репликации на основе Skytools. Пользователи смогут тогда увидеть, как мы используем их вместе. Но мы пока не нашли времени, чтобы сделать всё это...

Вопрос №26

Как в Skype осуществляется миграция PostgreSQL между основными (major) версиями?

Марко Креэн, инженер компании Skype:
С помощью Londiste (компонент репликации в Skytools).

Вопрос №27

Николай:
Почему компании-хостеры не торопятся включать PostgreSQL в список предоставляемых услуг, продолжая предлагать в основном MySQL? Стоит ли ждать изменения ситуации и если да, то когда?

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Это та же самая проблема, которую мы имеем с приложениями сторонних разработчиков. Провайдеры осуществляют миграцию одними из последних, потому как они на самом деле не используют базы данных. Они довольно консервативны — как и разработчики сторонних приложений. Со временем ситуация точно изменится.

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

Вопрос №28

Собираются ли улучшать партицирование (partitioning)?

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Да, есть разговоры об улучшении синтаксиса, чтобы упростить процедуры обслуживания. Может быть, это войдет в 8.4, но я не пока уверен.

Вопрос №29

Планируется ли в будущем метод доступа index cover (уж не знаю, как по-русски)?

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Вы имеете в виду доступ к данным только через индекс (без доступа к «куче», heap)? Мы обсуждали эту идею в применении к таблицам «только для чтения», для которых заранее известно, что все записи в индексе являются актуальными. Причина, по которой мы не можем сделать это для read-write таблиц, заключается в том, что информация о видимости записи содержится только в «куче», но не в индексе.

Вопрос №30

Планируются ли в будущем аналоги IOT-таблиц Oracle или clustered indexes в MS SQL, Sybase?

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
У нас есть патч для чего-то похожего на clustered index под названием «Group Index Tuples» (GIT). Хейки [Хейки Линнакангас, Heikki Linnakangas] сделал основную работу в нём, но мне не удалось уговорить его найти время для дополнительной работы над патчем к 8.4. Поэтому сейчас это пока просто патч. Точно не понял, что имеется в виду под IO-tables в Oracle.

Фёдор Сигаев, ведущий разработчик PostgreSQL:
Это много раз обсуждалось, но практического патча пока не предоставлено. Первое приближение — GIT (Group Index Tuples) от Хейки, но патч еще не завершён.

Вопрос №31

Планируется ли в будущем компрессия индексов в виде Oracle или db2 for z/OS (последний вариант, наверное, предпочтительней)?

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
О, что-то похожее будет реализовано при внедрении Group Index Tuples от Хейки [Хейки Линнакангас, Heikki Linnakangas] (к сожалению, пока работа не завершена). Лично я был бы определённо рад появлению подобных возможностей.

Фёдор Сигаев, ведущий разработчик PostgreSQL:
Нет пока, потому что в Постгресе bottleneck [узкое место] сидит не в размере индексов, а в доступе к таблицам — каждую запись надо проверять на видимость данной транзакцией. Это побочный эффект [реализации СУБД, основанной на методе] версионности записей.

Вопрос №32

Планируется ли в будущем общий кэш для планов?

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Проблема с реализацией кэша плана запросов заключается в издержках при процессе инвалидации кэша. В данный момент мы не разработали эффективный алгоритм для этого. Мы могли бы заняться реализацией уже сейчас, но ведь если такой кэш будет работать медленнее, чем сам процесс подготовки запроса в сессии — кому это будет нужно?

Вопрос №33

Когда наконец будут хинты? Или хотя бы stored outlines, как в Oracle?

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Мы не думаем, что займёмся реализацией «хинтов», т. к. существующий оптимизатор запросов достаточно хорош. У нас есть механизм грубой настройки запросов (переменные enable_*), которые, как правило, могут помочь в большинстве случаев, когда оптимизатор всё же ошибается. Основная проблема с «хинтами» заключается в том, что [при их наличии] мы [разработчики PostgreSQL] перестаём понимать, когда же оптимизатор ошибается и перестаём его развивать. Кроме того, многие люди, настроив свои «хинты» на определённые массивы данных, могут получить совершенно другой уровень производительности системы при изменении этих данных.

Фёдор Сигаев, ведущий разработчик PostgreSQL:
В обозримом будущем даже не планируется. Считается, что если оптимизатор запросов ошибается, то надо править оптимизатор, а не добавлять хинты.

Вопрос №34

Планируется ли корректная поддержка Unicode в регулярных выражениях?

Фёдор Сигаев, ведущий разработчик PostgreSQL:
Сделайте патч — закоммитим. Просто на удивление редко запрашиваемая фича, раз в полгода. Там есть большие сложности с производительностью регулярных выражений в мультибайтовых кодировках.

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Ух, я не был в курсе, что у нас есть проблемы с поддержкой Unicode в регулярных выражениях. Что это за проблема? Никогда не слышал.

Вопрос №35

Планируется ли ввести в PostgreSQL механизмы, аналогичные 'EVENTS' в MySQL? Это позволило бы, например, в наименее загруженное время суток самой базе производить VACUUM FULL ANALYZE или производить анализ данных и кластеризацию таблиц.

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Этот вопрос перекликается с одним из предыдущих, о планировщике. Я думаю, что проекты-спутники (например, pgevents) наилучшим образом подходят в данном случае.

Вопрос №36

Дмитрий:
Планируется ли введение встроенной мульти-мастер репликации? Если да, то когда можно ожидать beta-версию?

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Мы могли бы попробовать реализовать мульти-мастер репликацию, но блокировки зачастую делают её малопроизводительной. Большинство разработчиков считает мастер/слейв репликацию или партицирование данных по серверам лучшей альтернативой. PgPool, кстати, может работать в мульти-мастер режиме. PgCluster реализует мульти-мастер, но его производительность оставляет желать лучшего. Slony-II пытался реализовать мульти-мастер, но опять же-таки производительность была невысокой.

Фёдор Сигаев, ведущий разработчик PostgreSQL:
Есть планы на встроенную репликацию Master-Multiple Slaves, надеемся, что это будет в 8.4. Про Multi-Master — посмотрите на Postgres-R, его исходные коды открыты уже месяц как.

Марко Креэн, инженер компании Skype:
Если Вы хотите распределить нагрузку по записи на несколько машин, посмотрите PL/Proxy — он не является мульти-мастером в общепринятом смысле этого слова, но он обладает очень хорошей производительностью, которой так не хватает в обычных мульти-мастер системах.

Вопрос №37

Арлен
У меня, скорее, филосовский вопрос, чем практический. Не рассматривает ли сообщество PostgreSQL вопрос о смене лицензии с BSD на GPL ввиду быстрого роста популярности открытого кода и защиты его от закрытия крупными компаниями, взявшим PostgreSQL себе на вооружение и для наживы ради?

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Это действительно интересный вопрос. GPL могла бы предотвратить коммерциализацию Постгреса некоторыми компаниями, но тогда они бы не нашли деньги для финансирования разработки или спонсорства, поэтому мне кажется, что GPL является худшей альтернативой для нас. Если отвечать буквально на Ваш вопрос, никто в Постгрес-сообществе никогда всерьёз не рассматривал возможность изменить лицензию на GPL; она не имеет ни одного преимущества, зато имеет множество недостатков.

Фёдор Сигаев, ведущий разработчик PostgreSQL:
Нет, и не планируется. GPL накладывает излишние ограничения.

Вопрос №38

sakalr:
Cегодня только получил книгу с материалом по PL/PgSQL, потому слегка в растерянности, так как ещё не читал её. С одной стороны, возможно, в ней есть большинство ответов на мои вопросы, с другой стороны, подобные конференции проводятся не каждый месяц и глупо было бы не спросить здесь. Можете ли Вы порекомендовать обзорные статьи или рецепты (cookbook) на тему pl/pgsql? Сам reference в руководстве вполне толковый, но нужны именно рецепты.

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Ух, раньше у нас была книга рецептов по plpgsql, но я сейчас не вижу её онлайн. Я бы начал с изучения в src/test/regress/sql/plpgsql.sql на Вашем месте.

Вопрос №39

Алексей:
Когда можно ожидать реализацию нормальной репликации между двумя PostgreSQL-серверами, хотя бы master-slave с горячим переключением с master на slave? PITR не подходит нормально нагруженной среде из-за длительности переключения на резервный сервер, а сделанные на коленке и триггерах системы вроде Slony в сколько-нибудь серьезный продакшн ставить страшно.

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Проблема с failover-ом (переключением нагрузки на резервный сервер при отказе основного), встроенным в PostgreSQL, заключается в том, что мы не знаем достаточно о Вашей операционной системе, чтобы произвести переключение. Я боюсь, что автоматический failover будет сильно зависеть от ОС и, следовательно, он будет создаваться либо самим пользователем, либо тем, кто создает пакеты для его системы.

Вопрос №40

Алексей:
Можно ли изменить формат выходного представления типа UUID, чтобы получать на выходе просто 32-х символьную строку, а не разбитую по группам? В основном, входные данные именно varchar(32) в большинстве проектов, а то, что получается сейчас на выходе, неудобно использовать.

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Мы обсуждали возможность добавления форматирования вывода UUID в PostgreSQL 8.4. Я не припомню, сделано это уже или нет, но мне кажется, что Вы всегда можете использовать PL/PgSQL, чтобы форматировать UUID так, как Вам нравится.

Вопрос №41

Арлен:
Очень хотелось бы узнать, идут ли уже сейчас обсуждения в сообществе того, что войдёт в PostgreSQL 9-ой версии?

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Вау, PostgreSQL 9.0. Мне кажется, никто еще не загадывал так далеко вперёд. Мы работаем над 8.4 и не строим далеких 9.0 планов. Извините.

Вопрос №42

Арлен:
Хотелось бы узнать ваше отношение к проекту Postgres-R (http://www.postgres-r.org/) и мнение насчет его будущего в проекте PostgreSQL.

Брюс Момджан, лидер сообщества PostgreSQL, эксперт компании EnterpriseDB:
Postgres-R реализовал мульти-мастер репликацию на основе группового сетевого взаимодействия. В Slony-II разработчики попытались использовать подобный подход, но столкнулись с плохой производительностью и отказались от этого пути. Кто-то сейчас работает над Postgres-R, но я не уверен, что они имеют хорошие показатели производительности. Когда у нас будут данные о ней, можно будет обсуждать проект подробнее.

Слайды II встречи Российского PostgreSQL-сообщества

Wed, 14 May 2008 04:00:00 GMT

Слайды дискуссии, проведенной на второй встрече Российского PostgreSQL-сообщества в мае 2008 г. Встреча состояла из 3 частей:

Доклад "Производительность PostgreSQL в веб-приложениях" (Иван Золотухин)
Краткое выступление, посвященное PgBouncer (Максим Богук, Иван Золотухин)
Конференции, доклады, новости, текущие дела (Николай Самохвалов)

Спецкурс «PostgreSQL: промышленная разработка баз данных» (ВМК МГУ)

Mon, 28 Apr 2008 13:40:21 GMT

Объявления

[2008-05-27] Второй (и последний) раунд проведения экзамена состоится завтра, 28 мая, В 18:30 в П-5.

[2008-05-10] Опубликована программа экзамена (PDF). Экзамен состоится 14 мая, в 18:30, в аудитории П-5. (Если возникает конфликт с зачётами по другим предметам, можно приходить на второй день сдачи, 28 мая.)

[2008-04-30] Занятие 30 апреля не состоится. Следующее занятие: 7 мая, оно будет последним. До 7 мая принимаются результаты выполнения задания из лекции №8.

[2008-04-28] В материалах 8-го занятия (PDF) содержится описание комплексного задания (из 8 пунктов). Ответы (в свободной форме) присылать, как обычно, по email. Результаты выполнения обязательно будут учитываться на экзамене.

Материалы

Материалы занятий

Занятие 1: PDF
Занятие 2: PDF
Занятие 3: PDF
Занятие 4: PDF
Занятие 5: PDF
Занятие 6: PDF
Занятие 7: PDF
Занятие 8: PDF
Занятия 9 и 10: PDF

Метаинформация

Программа курса: PDF
Объявление: PDF

Экзамен

Программа экзамена: PDF

Литература

Основная литература

PostgreSQL Reference Manual - Volume 1: SQL Language Reference ― The PostgreSQL Global Development Group, 2007. http://www.postgresql.org/docs/8.3/interactive/
Гарсиа-Молина, Г. Системы баз данных. Полный курс ― М., СПб.: ИД "Вильямс", 2004.
Кузнецов, С. Д. Основы баз данных ― М.: Интернет-университет информационных технологий, http://intuit.ru, 2005. /*на сайте intuit.ru есть версия online*/
Бартунов О. Что такое PostgreSQL? // Корпоративные базы данных-2005 ― М.: ЦИТ, 2005. http://postgresmen.ru/articles/view/57

Дополнительная литература

SQL:2006. ISO/IEC JTC 1/SC 32. / Editor: Jim Melton. International Standard. ISO, ANSI, 2006. (drafts: http://wiscorp.com/SQLStandards.html)
Дейт, К.. Введение в системы баз данных. 7-е изд. ― М., СПб.: Вильямс, 2000.
Бартунов О., Сигаев Ф. Введение в полнотекстовый поиск в PostgreSQL ― М.: ЦИТ, 2007. http://www.citforum.ru/database/postgres/fts/
Самохвалов Н. PostgreSQL 8.3 http://postgresmen.ru/articles/view/78
Hellerstein, J. M., Naughton, J. F., Pfeffer, Avi. Generalized search trees for database systems. // Proceedings of the 21st International Conference on Very Large Data Bases. Zurich, Switzerland, 1995. (PDF)
Douglas, K. PostgreSQL (2nd Edition) ― Sams, 2005.
Worsley, J. C., Drake, J. D. Practical PostgreSQL ― O'Reilly Media, 2002.

О курсе

Специальный курс для студентов 4, 5 курса и аспирантов, читается во 2 семестре (весна 2008)
Лекции - 32 часа
Форма контроля: экзамен
Кафедра системного программирования ВМиК МГУ
Лектор: Самохвалов Николай Александрович

Учебно-практический курс «PostgreSQL: промышленная разработка баз данных» посвящён
особенностям практического использования СУБД PostgreSQL при разработке современных
программных продуктов. Основная цель курса — закрепление теоретических знаний,
полученных при прослушивании курсов по базам данных и SQL, и обеспечение возможности
практического применения этих знаний слушателями. Базовые темы рассматриваются в
контексте стандарта языка ISO/ANSI SQL, что делает возможным применение полученных в
процессе прослушивания курса знаний и навыков при использовании других СУБД.

Существенная часть лекций курса предполагает выполнение практических заданий (как
самостоятельно студентом, так и во время занятий, в группе), основанных на решениях,
применяемых в коммерческих продуктах и продуктах с открытым исходным кодом.
Особое внимание уделено следующим аспектам:
   ● соотношение возможностей СУБД PostgreSQL и стандарта языка SQL (SQL:1999 и SQL:
      2003);
   ● проблемы производительности и масштабирования и методы их решения;
   ● специальные возможности PostgreSQL и их роль в решении практических задач;
   ● практические задачи и методы их решения.

Курс рассчитан на аудиторию, обладающую базовыми знаниями в области баз данных и языка
SQL.

PostgreSQL 8.3: улучшение производительности в разы

Sun, 17 Feb 2008 17:57:18 GMT

Иван Золотухин (iz at postgresmen dot ru), февраль 2008

Миграция одного из проектов (2GB OLTP база с 150 довольно сложных транзакций в секунду на среднем по производительности сервере), в которых мы принимаем участие, с PostgreSQL 8.2 на 8.3 принесла удивительные результаты: производительность системы улучшилась в разы. Судите сами: около 21:00 (см. самый большой пик на графике чтения/записи) был сделан дамп базы версии 8.2 и восстановление дампа в 8.3. Соответственно на всех графиках в левой части система работает на PostgreSQL 8.2, справа после 21:00 — PostgreSQL 8.3. Нагрузка на сервер баз данных в дневное время (приблизительно с 7:00 до 23:00) слева и справа одинакова — 130-150 TPS. Конфигурация PostgreSQL практически не менялась: custom-настройки старого postgresql.conf были перенесены в новый, остальные параметры остались без изменений. Ниже приведено описание каждой картинки.

Рис. 1. Объем чтения/записи на диск с $PGDATA в сек (с 5-минутным усреднением). Стоит отметить, что WAL вынесен на отдельное устройство и не участвует в формировании картины. Так как объем базы невелик и она укладывается в оперативную память (а именно в shared_buffers), чтение практически отсутствует. Объем записи в 8.2 на порядок превосходит объем записи в 8.3. Самые высокие пики записи справа и слева вызваны checkpoint-ами (контрольными точками). Вблизи 23:30 виден пик, связанный с ежесуточным backup-ом базы.

Рис. 2. Средняя загруженность сервера PostgreSQL (LA, Load Average). В данном случае из-за довольно активной записи LA обусловлено iowait-ом, поэтому точно так же повторяет профиль поведения записи на диск с рис. 1: самые большие пики связаны с checkpoint-ами.

Рис. 3. Количество запросов на чтение/запись в сек (с 5-минутным усреднением).

Причины улучшения производительности

Читающие транзакции не приводят к проматыванию идентификатора транзакции (xid), соответственно отсутствует запись в pg_clog, которая раньше имела место быть даже при немодифицирующих запросах.
Распределенные checkpoint-ы. PostgreSQL научился «размазывать» процесс синхронизации буферов с файлами данных на диске, более равномерно распределяя нагрузку на систему.
Улучшенные seqscan-ы. Речь идет не только о Syncronized Scans, но еще и о том, что раньше seqscan по большой таблице, которая не лежит в shared_buffers, приводил к вытеснению «грязных» буферов из памяти и PostgreSQL вынужден был прямо сразу записывать их на диск (даже при простом немодифицирующем запросе). Начиная с версии 8.3 существует специальный буфер фиксированного размера для последовательных просмотров и PostgreSQL читает данные с диска в него, не вытесняя при этом существенные порции «грязных» данных на диск, как это было раньше.

Результаты

Существенно более гладкое распределение нагрузки на подсистему ввода-вывода и, как следствие, общей нагрузки на сервер c СУБД PostgreSQL; снижение общей загруженности сервера в 2-3 раза. Рекомендуем запланировать миграцию на PostgreSQL 8.3 всех инсталляций PostgreSQL младших версий с повышенной нагрузкой на подсистему ввода-вывода.

Слайды I встречи Российского PostgreSQL-сообщества

Thu, 14 Feb 2008 21:00:18 GMT

Слайды дискуссии, проведенной на первой встрече Российского PostgreSQL-сообщества в феврале 2008 г. Встреча состояла из нескольких частей:

Доклад "Что нового в PostgreSQL 8.3?" (Николай Самохвалов)
Краткое выступление, посвященное миграции на PostgreSQL 8.3 (Иван Золотухин)
Дискуссия о планах и будущей активности сообщества (Николай Самохвалов)

В дискуссиях на встрече принимали активное участие Олег Бартунов, Фёдор Сигаев, Максим Богук, Алексей Борзов и многие другие.

PostgreSQL 8.3

Mon, 8 Oct 2007 00:00:00 GMT

Николай Самохвалов (nikolay at postgresmen dot ru), октябрь 2007

8 октября 2007 года Джош Беркус (Josh Berkus) объявил о выходе PostgreSQL 8.3beta1 (см. официальный Changelog). Более полугода потребовалось разработчикам для того, чтобы завершить работу по обработке патчей (напомним, feature freeze состоялся 1-го апреля 2007 года). Так что самое время рассказать, чем же порадует нас в этот раз самая развитая из открытых СУБД в мире.

Я разобью весь список на четыре части. В первой, для многих самой важной, части я перечислю изменения, которые так или иначе касаются производительности. Во второй — приведу список новых возможностей для программистов баз данных, призванных ещё более расширить и без того неслабый набор «фич» PostgreSQL. Третья часть посвящена нововведениям, предназначенным для администраторов баз данных. И, наконец, в конце я упомяну некоторые Open Source проекты, которые являются проектами-спутниками Постгреса (другими словами, имеют свой собственный цикл разработки).

Производительность

Начнём с того, что сегодня (на данный момент стабильная ветка — 8.2, актуальная версия — 8.2.5) PostgreSQL успешно тягается в плане производительности не только с OpenSource-альтернативами, но и с ведущими коммерческими СУБД. Такими как Oracle. Это уже не пустой звук — взгляните на результаты тестирования, проведённого в компании Sun. Медленных слонов больше нет! Богатейший набор типов индексов, широчайшие возможности тюнинга системы, работа с очень большими объёмами и нагрузками, хороший выбор систем репликации и масштабирования — всё это «по зубам» современным слонам. Даже скорость разработки выгодно отличает Постгрес по сравнению с другими СУБД: каждый год мы неизменно получаем существенный шаг вперёд.

Что же нового в PostgreSQL версии 8.3 в плане производительности? Многие изменения нетривиальны. По словам координатора разработки PostgreSQL Брюса Момджана (Bruce Momjian), нанёсшего не так давно по приглашению компании «Постгресмен» визит в Москву , та работа по оптимизации производительности системы, которой заняты разработчики Постгреса в последние годы, является чрезвычайно сложной. Каждый шаг требует всё более и более существенных трудозатрат, занимает всё больше времени и сил разработчиков.

Одним из таких действительно нетривиальных изменений можно смело считать «фишку» под названием HOT (Heap Only Tuples). Это, пожалуй, одно из самых существенных изменений в плане производительности. Чтобы понять, в чём заключается данное изменение, необходимо вспомнить, что PostgreSQL реализует так называемую мультиверсионную модель разграничения доступа (MVCC, Multi-Version Concurrency Control).

Суть HOT в следующем. Ранее, до реализации данного подхода, при обновлении строки в таблице каждая новая её версия приводила к появлению новых версий всех индексов, независимо от того, затрагивали ли данные изменения проиндексированные столбцы или нет (см. рис. «Обновление без HOT»). Теперь же, если новая версия строки попадает в ту же страницу памяти, что и предыдущая, и столбцы, по которым был создан индекс, не изменялись, индекс остаётся прежним. Но это ещё не всё. Если есть такая возможность, происходит «моментальное» повторное использование места в странице Heap. Что, естественно, сокращает объём работы, производимой при операции VACUUM. На рис. «HOT-обновление» схематически отображено, каким образом происходит теперь обновление строки.

Следующая новинка придётся по вкусу, прежде всего, большому количеству веб-разработчиков. Начиная с версии 8.3 любую транзакцию в PostgreSQL можно делать «асинхронной».

Это означает, что при выполнении операции фиксации транзакции (COMMIT) сервер PostgreSQL не будет ждать завершения дорогостоящей операции синхронизации журнала транзакций (WAL fsync). Другими словами, транзакция будет считаться успешно завершённой сразу же, как только все логические условия будут выполнены (проверены все необходимые ограничения целостности). Физически запись в журнал транзакций произойдёт через очень малый промежуток времени (как правило, для нормально функционирующих систем это максимум 200-1000 мс).За состояние транзакции (синхронная/асинхронная) отвечает переменная окружения synchronous_commit. Перейти в асинхронный режим просто:

SET synchronous_commit TO OFF;

Стоит отметить, что асинхронные транзакции не являются альтернативой режиму работы сервера с отключенной операций fsync. Дело в том, что режим fsync=off может привести к получению несогласованного состояния базы (к примеру, в случае непредвиденного отказа оборудования или потери питания) и рекомендуется только в тех случаях, когда используется оборудование высокой надёжности (например, контроллер дисков с батарейкой). Использование же новой возможности никак не может привести к рассогласованию данных. Максимум, что возможно, это потеря небольшой порции данных (опять-таки, в случае жёсткого сбоя сервера — ошибки ОС, оборудования, сбой питания). Типичным примером для асинхронных транзакций может служить задача сохранения большого количества информации в таблицу-журнал (например, лог действий пользователя), когда потеря нескольких строк не является критичной. При этом все важные транзакции могут по-прежнему быть синхронными.

Ещё одно улучшение в области производительности относится к ситуациям, когда при выполнении запросов PostgreSQL последовательно просматривает таблицы (операция SeqScan). Если до версии 8.3 в таких случаях нередко возникали ситуации, когда разные процесса Постгреса одновременно делали одну и ту же работу — просматривали одну и ту же таблицу — то теперь, благодаря реализации Synchronized Scans («синронизованные просмотры»), в один и тот же момент времени для одной таблицы может проводиться не более одной операции просмотра. Достигается это следующим образом. Если в рамках какой-либо сессии требуется проведение SeqScan-а для некоторой таблицы, для которой уже выполняется SeqScan (для другой сессии), то произойдёт «прыжок на ходу» к результатам уже выполняющегося SeqScan-а. По завершении данного процесса, если это необходимо, будет осуществлён «добор» результатов с помощью ещё одного неполного SeqScan-а (см. рис).

Работа над уменьшением стресс-эффекта, производимого выполнением системой процессов checkpoint («контрольная точка») продолжается: теперь checkpoint-ы выполняются не сразу, а постепенно: процесс как бы «размазан» во времени. Отсюда и название данного изменения — checkpoint smoothing. Стоит отметить, что при штатном выключении сервера и проведениия «явной» операции checkpoint (команда CHECKPOINT) запись данных на диск по-прежнему будет производиться с максимально возможной скоростью.

В завершение разговора о производительности, приведём краткий перечень других изменений, призванных улучшить быстродействие систем, использующих PostgreSQL:

теперь autovacuum включён по умолчанию;
в некоторых ситуациях теперь возможнен запуск сразу нескольких процессов autovacuum (например, при продолжительном процессе чистки большой таблицы, небольшие таблицы теперь не вынуждены ждать завершения данного процесса);
заметное уменьшение дискового пространства, занимаемого базами данных: 1) за счёт заголовков varlena-типов (типы данных переменной длины: текст, массивы и т. п.), которые ранее занимали строго 4 байта, а теперь в некоторых ситуациях всего 1 байт; 2) за счёт экономии заголовков строк таблицы (ранее 27 байт, теперь — 24);
выполнение транзакций, не модифицирующих данные, не приводит к увеличению значения счётчика транзакций (xid), что существенно снижает вероятность ситуации «перекрытия» счётчика транзакций (xid wraparound); кроме того, данное изменение является значительным шагом вперёд к реализации встроенной Master-Slave репликации на основе трансфера журнала транзакций — теперь не возникнет рассинхронизации счётчика xid между Master- и Slave-узлами;
реализован механизм автонастройки параметров процесса bgwriter (background writer — специальный процесс, занимающийся записью «грязных» разделяемых буферов на диск);
оптимизирован механизм получения результата для запросов с использованием «…ORDER BY … LIMIT…» (т. н., Top-N sorting): в некоторых случаях система удерживает необходимые страницы данных в оперативной памяти, что обеспечивает очень высокую скорость выдачи результата;
теперь можно задавать (пока только в виде двух констант) оценочную стоимость выполнения фунции и оценку количества рядов, которые она возвращает, что позволяет планнеру PostgreSQL выбирать лучший план запроса (пример: ALTER FUNCTION log_data(text) COST 100000 ROWS 1).

Разработчикам баз данных

Самое заметное и существенное изменение, которое следует здесь отметить, — это миграция модуля для полнотекстового поиска (contrib/tsearch2) в ядро системы. Разрабатываемый российскими разработчиками Олегом Бартуновым и Фёдором Сигаевым, tsearch2 долгое время являлся самым популярным contrib-модулем Постгреса. Патч для миграции полнотекстового поиска в ядро, который был принят этим летом в результате кропотливой и продолжительной работы (принятая версия патча — 58!) сразу нескольких ключевых разработчиков команды PostgreSQL, является самым большим за всю историю проекта.

Кроме того, что все возможности модуля tsearch2 теперь будут доступны по умолчанию и процессы миграции на новую версию PostgreSQL заметно упростятся, конфигурировать словари и правила обработки текстов теперь станет проще: все основные операции по конфигурированию осуществляются с помощью SQL-команд. Вот так, например, можно создать простой словарь-тезаурус:

СREATE TEXT SEARCH DICTIONARY thesaurus_astro ( 
    TEMPLATE = thesaurus, 
    DictFile = thesaurus_astro, 
    Dictionary = english_stem 
); 
ALTER TEXT SEARCH CONFIGURATION russian 
    ADD MAPPING FOR lword, lhword, lpart_hword 
        WITH thesaurus_astro, english_stem;

Упростились и процессы создания индекса. Пример создания GIN-индекса над обычным текстовым столбцом (без создания дополнительных столбцов и триггеров):

CREATE INDEX pgweb_idx ON pgweb 
    USING gin(to_tsvector('russian', title || body));

А вот пример запроса с ранжированием по релевантности, использующий к тому же специальную функцию plainto_tsquery для получения tsquery (позволяет забыть об экранировании символов и быстро и просто преобразовать обычный текст в tsquery):

SELECT 
    ts_rank_cd(textsearch_index, q) AS rank, title 
FROM 
    pgweb, plainto_tsquery('supernova star') q 
WHERE 
    q @@ textsearch_index 
ORDER BY 
    rank DESC LIMIT 10;

Другое заметное изменение — поддержка XML, в работе над которой принимал участие автор данной статьи. Данный функционал реализован в соответствии со стандартом SQL:2003 (14-я часть стандарта, SQL/XML).

Прежде всего, появился специальный тип данных xml, встроенный в ядро. При использовании данного типа, сервер проверяет, правильно ли сформированы данные (проверка на well-formedness). Причём возможны варианты использования, при которых разрешена работа с частями документа (это позволяет обеспечить свойство «замкнутости» функций для работы с XML на тип данных xml).

В соответствии со стандартом SQL:2003 реализован набор функций для преобразования реляционных данных в XML (т. н., функции публикации SQL/XML). Вот простой пример запроса на формирование XML-данных:

SELECT XMLROOT ( 
   XMLELEMENT ( 
      NAME 'some', 
      XMLATTRIBUTES ( 
         'val' AS 'name', 
         1 + 1 AS 'num' 
      ), 
      XMLELEMENT ( 
         NAME 'more', 
         'foo' 
      ) 
   ), 
   VERSION '1.0', 
   STANDALONE YES 
);

Кроме того, реализована поддержка DTD-валидации (функция xmlvalidatedtd()), поддержка оценки XPath-выражений (функция xpath(), возвращающая массив из данных типа xml ), и альтернативные функции для упрощённой публикации реляционных данных в виде XML (функции tabletoxml(), querytoxml() и другие).

Для ускорения выполнения запроса к XML-данным возможно использование функциональных btree-индексов и GIN-индексов, а также использования полнотекстового поиска для XML-данных. Приведём пример создания btree-индекса по результатам оценки XPath-выражения:

CREATE INDEX i_table1_xdata ON table1 USING btree( 
   ((xpath(’//person/@name’, xdata))[1]) 
);

Что касается типов данных, PostgreSQL 8.3 представляет целый ряд нововведений: помимо встроенных в ядро системы типов tsquery/tsvector и xml, появились следующие:

enum (перечислимые типы данных, определяемые пользователем) для удобства некоторых пользователей, в том числе мигрирующих с TheirSQL;
типы данных GUID/UUID (в виде contrib-модуля);
массивы составных типов (например, определённых пользователем типов).

И наконец, краткий список остальных изменений:

автоматическая инвалидация кэша плана запросов для PL/pgSQL-функций;
конструкции «CREATE FUNCTION … RETURNS TABLE» и «RETURN TABLE…» для создания функций, результатом которых является таблица;
поддержка операции обновления для курсоров;
стандартная (ISO/ANSI SQL) конструкция «ORDER BY … NULLS FIRST/LAST» для упрощения установки порядка следования NULL-значений (также помогает при миграции с других СУБД);
индексация NULL-значений в GiST-индексах.

Администраторам баз данных

Данный раздел получился куцым, ибо многое из того, что призвано улучшить жизнь DBA, описано выше :-) Тем не менее, расскажем кратко о том, что осталось.

В планах запросов (команда EXPLAIN ANALYZE) теперь видно, какой именно алгоритм сортировки был выбран и сколько памяти было израсходовано:

                       QUERY PLAN 
------------------------------------------------------- 
 Sort (cost=34.38..34.42 rows=13 width=176) (actual time=0.946..0.948 rows=6 loops=1) 
   Sort Key: obj2tag.o2t_tag_name 
   Sort Method: quicksort Memory: 18kB           <-- см. сюда! 
   -> Hash Join (cost=19.19..34.14 rows=13 width=176) (actual time=0.812..0.835 rows=6 loops=1) 
[...]

Специальный contrib-модуль pg_standby, написанный Саймоном Ригсом (Simon Riggs) упростит работу администраторам, настраивающим сервер «тёплого бэкапа» (Warm Standby) на основе трансфера журнала логов (WAL transfer). Модуль написан на чистом C, поэтому является легко расширяемым и портируемым на новые платформы (работоспособность проверена уже, по крайней мере, на Linux и Win32).

При определении функции теперь можно переопределять переменные окружения, которые будут действовать только в рамках выполнения данной функции (привязка значений переменных функциям). Например, вот так можно указать, что выполнение функции log _data() переключает транзакцию в режим асинхронности:

    ALTER FUNCTION log_data(text) 
        SET synchronous_commit TO OFF;

Ну и, по традиции, краткий список других новинок данного раздела:

поддержка интерфейса GSSAPI;
улучшенная сборка на платформе Win32 (теперь не требуется MinGW, сборка ведётся в MS VC++, что помимо прочего приводит к улучшению производительности в Windows);
создание таблиц по подобию с учётом индексов (пример: CREATE TABLE dict2 (LIKE dictionary INCLUDING INDEXES)).

Дополнительные проекты

Компания EnterpriseDB (сотрудники которой являются активным разработчиками PostgreSQL, многие изменения версии 8.3 в области производительности являются именно их заслугой) выпустила отладчик pldebugger, который представляет собой contrib-модуль, позволяющий отлаживать PL/pgSQL-функции в стандартном инструменте для администрирования pgAdminIII и осуществлять профайлинг.

Проект в данный момент существует в виде независимого contrib-модуля (представлен на PgFoundry) и работает на большом количестве платформ (включая Linux и Win32). Стоит отметить, что данный модуль работает и с версией 8.2 Постгреса.

Как мы рассказывали не так давно, компания Skype (которая использует в широко известном одноимённом проекте именно PostgreSQL) выпустила в Open Source сразу несколько продуктов, которые могут быть полезны большому кругу разработчиков. Среди них прежде всего стоит отметить псевдо-язык PL/Proxy, позволяющий организовывать горизонтальное масштабирование практически без ограничений (при условии, если вся бизнес-логика приложения реализована в виде хранимых процедур), чрезвычайно лёгкий менеджер соединений PgBouncer. Загляните на страничку Skype Developers Zone, вы найдёте много интересного!

На рубеже весны и лета 2007-го года вышла версия 1.0 простого и удобного инструмента для анализа логов pgFouine. Данная программа поможет вам узнать, чем же занимался ваш процессор (процессоры) сервера баз данных. pgFoiune анализирует логи запросов Постгреса (при включении журнализации запросов рекомендуется вводить ограничение по времени снизу, см. описание параметра log_min_duration_statement), предоставляя отчёты по самым медленным запросам, ошибкам и общую статистику (см. примеры). Тем самым данный инструмент позволяет разработчику баз данных понять, какие запросы можно улучшить, чтобы ускорить работу приложения, использующего PostgreSQL.

И наконец, кратко об остальных продуктах:

проект pgSNMP является реализацией SNMP-агента для PostgreSQL (мониторинг состояния сервера);
SEPostgres – расширение, основанное на модели обеспечения усиленной безопасности SELinux;
создан инструмент, создающий рекомендации администратору баз данных по созданию индексов и показывающий возможный план выполнения запроса при условии наличия таких индексов (Index Advisor);
в известном инструменте для web-администрирования phppgadmin появились (или вот-вот появятся) возможности настройки Slony-кластера, полнотекстового поиска, параметров автовакуума.

Заключение

Версия 8.3 является очередным шагом на пути к полноценной системе управления баз данных для корпоративного использования. Нетривиальные улучшения в области производительности, появление возможностей, которые продиктованы нуждами пользователей, расширение множества проектов-спутников — всё это демонстрирует уверенное и быстрое развитие PostgreSQL.

При написании данного обзора автор использовал следующие источники:

pgwiki/WhatsNew83
pgwiki/Feature_Matrix
pgwiki/8.3_Changelog
pgwiki/Todo:PatchStatus
Доклад Брюса Момджана на конференции Highload-2007, Москва (pdf).
Официальная документация PostgreSQL 8.3.
Архив рассылки pgsql-hackers.

PostgreSQL: аналитика для DBA

Sat, 8 Sep 2007 19:54:28 GMT

Автор: Иван Золотухин

Многие пользователи СУБД PostgreSQL знают, что сервер во время своей работы собирает разнообразную статистику, но не все знают, что ее полезно анализировать и как ее извлекать для этого. В этом небольшом тулките собраны несколько полезных запросов, дающих некоторое представление о том, как использовать это "скрытое знание", которое постоянно копится. Эти запросы можно использовать для мониторинга состояния PostgreSQL (ручного или с помощью плагинов для систем мониторинга вроде Nagios, Cacti или Zabbix), для поиска узких мест в работе сервера и многих других подобных задач. Помните, что это лишь верхушка айсберга; в документации можно найти описания нескольких десятков системных представлений, которые также могут быть полезны администратору PostgreSQL.

Для корректной работы тулкита необходимо включить опции stats_block_level и stats_row_level в postgresql.conf, а также настроить параметр stats_reset_on_server_start по своему усмотрению. Если при каждом перезапуске сервера PostgreSQL вы меняете какие-то существенные параметры его конфигурации, имеет смысл обнулять статистику, чтобы отслеживать эффект внесенных изменений. Если же вас интересует долгосрочная перспектива и рестарт производится не вследствие изменения конфигурации PostgreSQL, ставьте параметр stats_reset_on_server_start в значение off.

Отношение hit / read

При выполнении запроса PostgreSQL сначала смотрит, есть ли нужные в запросе данные в разделяемой памяти (shared buffers). Если они найдены, засчитывается hit, если нет -- делается сравнительно медленный системный вызов fread для поднятия данных с диска или из дискового кеша операционной системы и засчитывается read. В среднем, верно правило: чем больше отношение hit/read, тем лучше настроен PostgreSQL, так как он очень мало читает с диска, в основном извлекая данные из разделяемой памяти. Для большинства не очень больших баз это отношение должно лежать в пределах 5000-10000. Не стремитесь, однако, искусственно завысить настройку shared_buffers, которая прямо определяет hit/read: слишком большие размеры разделяемой памяти ведут к потере производительности в базах с интенсивной записью. Также стоит помнить, что fread может быть довольно быстрым, если данные находятся в дисковом кеше ОС.

SELECT 
  datname, 
  CASE 
    WHEN blks_read = 0 THEN 0 
    ELSE blks_hit / blks_read 
  END AS ratio 
FROM 
  pg_stat_database;

Количество модификаций, произошедших в таблице

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

SELECT 
  relname, 
  n_tup_ins, 
  n_tup_upd, 
  n_tup_del 
FROM 
  pg_stat_user_tables 
ORDER BY 
  n_tup_upd DESC;

Статистика seq scan / index scan

Список по таблицам: какое количество запросов к ним было выполнено посредством последовательного просмотра; какое количество запросов было выполнено с использованием индексов; а также отношение этих двух чисел. Позволяет оценить, все ли нужные индексы созданы в данной таблице. Если ваши таблицы содержат более нескольких тысяч рядов, последовательный просмотр будет выполняться медленнее просмотра индекса, поэтому в идеальном случае seqscan-ов в таких таблицах быть не должно. Если у вас они все же есть, анализируйте запросы к таким таблицам и создавайте соответствующие индексы. При этом важно не перестараться: чем больше индексов по колонкам таблицы, тем дороже становятся операции обновления данных.

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

SELECT 
  relname, 
  seq_scan, 
  idx_scan, 
  CASE 
    WHEN idx_scan = 0 THEN 100 
    ELSE seq_scan / idx_scan 
  END AS ratio 
FROM 
  pg_stat_user_tables 
ORDER BY 
  ratio DESC;

Статистика по индексам

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

SELECT
  indexrelname,
  idx_tup_read,
  idx_tup_fetch,
  (idx_tup_read - idx_tup_fetch),
  CASE WHEN idx_tup_read = 0 THEN 0 ELSE (idx_tup_read::float4 -
idx_tup_fetch) / idx_tup_read END as r
FROM
  pg_stat_user_indexes
ORDER BY r desc;

Выполняющиеся запросы с их продолжительностью

Простой список выполняющихся сервером в настоящий момент запросов. Бывает полезен, когда вы недостаточно хорошо знаете систему или просто не успели ее настроить -- с его помощью можно найти и прервать "плохой" запрос, который мешает работе сервера (колонка procpid содержит PID процесса, которому можно сделать kill при необходимости). Помните, однако, что простой периодический просмотр выполняющхся запросов ни в коем случае не заменит замечательный анализатор логов pgFouine. Также не стоит забывать, что процесс, в котором вы выполняете данный запрос, тоже попадает в результирующий список.

SELECT 
  datname, 
  NOW() - query_start AS duration, 
  procpid, 
  current_query	
FROM
  pg_stat_activity 
ORDER BY duration DESC;

Список текущих блокировок

Список текущих блокировок с указанием типа блокировки, таблицы и базы данных, на которой она выставлена и номера транзакции, которая выставила блокировку. Не стоит пугаться, если запрос выдает длинный список lock-ов -- не все они являются критическими и блокирующими таблицу от всех возможных изменений и даже чтения. Для анализа списка блокировок обязательно стоит ознакомиться с документацией об их типах в PostgreSQL и о том, когда и какими запросами они выставляются. Один из распространенных случаев, когда список блокировок может пригодиться: выполняя команду ps aux | grep ^postgres вы видите, что в статусе одного из процессов postgres-а написано waiting -- это как раз и означает, что данный процесс ждет, когда будет снята нужная ему блокировка. Какая именно -- выясняйте, запустив данный запрос.

SELECT 
  l.mode, 
  d.datname, 
  c.relname, 
  l.granted, 
  l.transactionid 
FROM 
  pg_locks AS l 
LEFT JOIN pg_database AS d ON l.database= d.oid 
LEFT JOIN pg_class AS c ON l.relation = c.oid;

Автор выражает благодарность Максиму Богуку за ряд ценных замечаний.
Any feedback is welcome at iz at sai dot msu dot ru
Sep 2007

Библиотека полезных функций для PostgreSQL

Fri, 8 Jun 2007 00:20:08 GMT

Автор компиляции: Иван Золотухин

Данная статья содержит выборку PL/PgSQL и SQL функций, которые могут быть полезны разработчикам и администраторам PostgreSQL, а также всем желающим познакомиться с основными процедурными языками в СУБД PostgreSQL на работающих примерах. Большая часть этих функций обсуждалась в англоязычных рассылках и иных каналах общения членов сообщества PostgreSQL, некоторые функции написаны мною. Где это возможно, у функций приведены авторы и небольшие комментарии. Сам лист функций время от времени пополняется, так что следите за изменениями, если примеры представляют для вас интерес.

Генерация случайного пароля

Вариант 1

-- Author: Magnus Hagander
CREATE FUNCTION generate_random_password() RETURNS text
   AS $$
DECLARE
  j int4;
  result text;
  allowed text;
  allowed_len int4;
BEGIN
  allowed := '23456789abcdefghjkmnpqrstuvwxyzABCDEFGHJKMNPQRSTUVWXYZ&#%@';
  allowed_len := length(allowed);
  result := '';
  WHILE length(result) < 16 LOOP
     j := int4(random() * allowed_len);
     result := result || substr(allowed, j+1, 1);
  END LOOP;
  RETURN result;
END;
$$
   LANGUAGE plpgsql;

Вариант 2

-- Author: Jeff Ross
CREATE OR REPLACE FUNCTION gen_password() RETURNS text AS $$
DECLARE
  password text;
  chars text;
BEGIN
  password := '';
  chars :=
'abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ0123456789';
  FOR i IN 1..8 LOOP
    password := password || SUBSTRING(chars,
ceil(random()*LENGTH(chars))::integer, 1);
  END LOOP;
  return password;
END;
$$
LANGUAGE plpgsql;

Работа с интервалами: сдвиг на N месяцев

Простая функция на языке SQL для добавления или вычитания из даты заданного количества месяцев.

-- Author: Martijn van Oosterhout
CREATE OR REPLACE FUNCTION GOMONTH(DATE, INTEGER, OUT DATE) IMMUTABLE AS
$_$
SELECT ($1 + ($2 * '1 MONTH'::INTERVAL))::DATE;
$_$ LANGUAGE SQL

Найти всех пользователей данной роли

Рекурсивная функция поиска всех ролей, принадлежащих данной роли. То есть, если роль ID1 имеет членов ID2 и ID3, а в роль ID2 входят роли ID4 и ID5, то функция вернет список всех этих ролей.

-- Author: David Fetter
CREATE OR REPLACE FUNCTION get_roles_under(OID)
RETURNS SETOF OID
LANGUAGE sql
AS $$
SELECT
   $1
UNION
SELECT
   member
FROM
   pg_catalog.pg_auth_members
WHERE
   roleid = $1
UNION
SELECT
   get_roles_under(roleid) AS "roleid"
FROM
   pg_catalog.pg_auth_members
WHERE
   roleid IN (
       SELECT
           member
       FROM
           pg_catalog.pg_auth_members
       WHERE
           roleid = $1
   )
$$;

Kill бакенда и получение имени текущего пользователя

Довольно глупый, но тем не менее reference-пример прекращения работы бакенда и получения имени пользователя, вызывающего функцию:

CREATE FUNCTION kill_process(integer) RETURNS boolean
AS 'SELECT pg_cancel_backend(procpid)
     FROM (SELECT procpid FROM pg_stat_activity WHERE procpid=$1 and usename=session_user)
AS kill;'
LANGUAGE SQL SECURITY DEFINER;

Начало и конец недели по ее номеру в году

Работа с функциями, связанными со временем:

-- Author: Andreas Kretschmer
create or replace function get_week(IN jahr int, IN kw int) returns text as $$
declare
       datum   date;
       ret     text;
begin
       datum = (jahr || '-01-01')::date;

       loop
               exit when extract(dow from datum) = 4;
               datum = datum + '1day'::interval;
       end loop;
       ret = to_char(datum+(7*(kw-1)-3||'days')::interval,'dd-mm-yyyy') || ' - ' || to_char(datum+(3+7*(kw-1)||'days')::interval,'dd-mm-yyyy');
       return ret;
end;
$$ language plpgsql immutable strict;

-- Example:
test=# select get_week(2007,2);
        get_week         
-------------------------
 08-01-2007 - 14-01-2007

Манипуляции с хозяином/пермиссиями таблиц и функций в схеме

Таблицы

Функция для изменения прав доступа к таблицам в заданной схеме по заданной LIKE-маске. Администраторам должно быть удобно на основании этого прототипа также сделать функции revoke_on_tables() и change_owner_of_tables() -- они будут использовать абсолютно такой же цикл, только динамический SQL внутри него будет несколько иной.

-- Author: Ivan Zolotukhin
-- License: BSD
CREATE OR REPLACE FUNCTION grant_on_tables(role_name text, permission text, mask text, schema_name text)
RETURNS integer LANGUAGE plpgsql 
	AS $$
-- Function that grants given permissions to given role on tables with given LIKE mask within given schema
-- Example:
--   SELECT grant_on_tables('role_developer','SELECT, INSERT, UPDATE, DELETE, RULE, REFERENCE, TRIGGER','%','public');
-- will grant all the maximum permissions on all tables within public schema to role_developer role
DECLARE
	obj record;
	num integer;
BEGIN
	num := 0;
	FOR obj IN 
		SELECT 
			relname 
		FROM 
			pg_class c
		JOIN pg_namespace ns ON (c.relnamespace = ns.oid) 
		WHERE
			relkind in ('r','v','S') 
			AND nspname = schema_name 
			AND relname LIKE mask
		ORDER BY
		    relname
	LOOP
		EXECUTE 'GRANT ' || permission || ' ON ' || obj.relname || ' TO ' || role_name;
		RAISE NOTICE '%', 'Done: GRANT ' || permission || ' ON ' || obj.relname || ' TO ' || role_name;
		num := num + 1;
	END LOOP;
	RETURN num;
END;
$$;

Функции

Эта функция является вспомогательной и как правило ее не нужно вызывать руками. Она нужна для получения необходимой информации об аргументах функций, так как в PostgreSQL для манипуляций с хозяином или пермиссиями функции требуется указывать fully-qualified имя со списком аргументов.

-- Author: Ivan Zolotukhin
-- License: BSD
CREATE OR REPLACE FUNCTION pg_get_function_args( 
	IN funcname character varying, 
	IN funcargs oidvector,	
	IN schema character varying, 
	OUT pos integer, 
	OUT direction character, 
	OUT argname character varying, 
	OUT datatype character varying) RETURNS SETOF RECORD 
	AS $$
-- For a function name and schema, this procedure selects for each argument the following data: 
-- 		- position in the argument list (0 for the return value) 
--		- direction 'i', 'o', or 'b' 
--		- name (NULL if not defined) 
--		- data type
DECLARE 
	rettype character varying; 
	argtypes oidvector; 
	allargtypes oid[]; 
	argmodes "char"[]; 
	argnames text[]; 
	mini integer; 
	maxi integer; 
BEGIN 
	/* get object ID of function */ 
	SELECT INTO 
		rettype, 
		argtypes, 
		allargtypes, 
		argmodes, 
		argnames 
		CASE 
			WHEN 
				pg_proc.proretset 
			THEN 
				'setof ' || pg_catalog.format_type(pg_proc.prorettype, NULL) 
			ELSE 
				pg_catalog.format_type(pg_proc.prorettype, NULL) 
		END, 
		pg_proc.proargtypes, 
		pg_proc.proallargtypes, 
		pg_proc.proargmodes, 
		pg_proc.proargnames 
	FROM 
		pg_catalog.pg_proc 
	JOIN pg_catalog.pg_namespace ON (pg_proc.pronamespace = pg_namespace.oid) 
	WHERE 
		pg_proc.proname = funcname 
		AND pg_proc.proargtypes = funcargs
		AND pg_namespace.nspname = schema 
		AND pg_catalog.pg_function_is_visible(pg_proc.oid); 

	/* bail out if not found */ 
	IF NOT FOUND THEN 
		RETURN; 
	END IF; 

	/* return a row for the return value */ 
	pos = 0; 
	direction = 'o'::char; 
	argname = 'RETURN VALUE'; 
	datatype = rettype; 
	RETURN NEXT; 

	/* unfortunately allargtypes is NULL if there are no OUT parameters */ 
	IF allargtypes IS NULL THEN 
		mini = array_lower(argtypes, 1); 
		maxi = array_upper(argtypes, 1); 
	ELSE 
		mini = array_lower(allargtypes, 1); 
		maxi = array_upper(allargtypes, 1); 
	END IF; 

	IF maxi < mini THEN 
		RETURN; 
	END IF; 

	/* loop all the arguments */ 
	FOR i IN mini .. maxi 
	LOOP 
		pos = i - mini + 1; 
		IF argnames IS NULL THEN 
			argname = NULL; 
		ELSE 
			argname = argnames[i]; 
		END IF; 

		IF allargtypes IS NULL THEN 
			direction = 'i'::char; 
			datatype = pg_catalog.format_type(argtypes[i], NULL); 
		ELSE 
			direction = argmodes[i]; 
			datatype = pg_catalog.format_type(allargtypes[i], NULL); 
		END IF; 
		RETURN NEXT; 
	END LOOP; 
	RETURN; 
END;$$ 
LANGUAGE plpgsql STABLE STRICT SECURITY INVOKER;

А этот пример представляет непосредственный интерес. Функция выдает необходимые пермиссии всем функциям с названиями, удовлетворяющим LIKE-маске в заданной схеме:

-- Author: Ivan Zolotukhin
-- License: BSD
CREATE OR REPLACE FUNCTION grant_on_functions(role_name text, permission text, mask text, schema_name text)
RETURNS integer LANGUAGE plpgsql 
	AS $$
-- Function that grants given permissions to given role on functions with given LIKE mask within given schema
-- Example:
--   SELECT grant_on_functions('role_developer','EXECUTE','%','public');
-- will grant the execute permission on all functions within public schema to role_developer role
DECLARE
	func record;
	func_argument record;
	argument_list varchar;
	num integer;
BEGIN
	num := 0;
	/* select all function's names in given schema */
	FOR func IN 		
		SELECT
			proname, proargtypes
		FROM
			pg_proc AS pro
		JOIN pg_namespace AS ns ON pro.pronamespace = ns.oid
		WHERE
			ns.nspname = schema_name
			AND proname LIKE mask
			AND pg_catalog.pg_function_is_visible(pro.oid)
	    ORDER BY
	        proname
	LOOP
		argument_list := '(';
		-- get input arguments of the function we're granting permissions on
		FOR func_argument IN
			SELECT datatype FROM pg_get_function_args(func.proname::varchar, func.proargtypes::oidvector, schema_name) WHERE direction = 'i'
		LOOP
			argument_list := argument_list || func_argument.datatype || ', ';
		END LOOP;
		
		SELECT INTO argument_list rtrim(argument_list, ', ');
		argument_list := argument_list || ')';
		
		-- grant permissions when we know complete function designation like
		-- my_best_function(varchar, text, integer, float)
		EXECUTE 'GRANT ' || permission || ' ON FUNCTION ' || schema_name || '.' || func.proname || argument_list || ' TO ' || role_name;
		RAISE NOTICE '%', 'Done: GRANT ' || permission || ' ON FUNCTION ' || schema_name || '.' || func.proname || argument_list || ' TO ' || role_name;
		num := num + 1;
	END LOOP;
	RETURN num;

END;
$$;

Как и в случае с таблицами, администратору может быть удобно использовать функцию change_owner_of_functions(), которая практически не будет отличаться от приведенного выше примера.

Any feedback is welcome at iz at sai dot msu dot ru
Jun 2007

Инструкция по оптимизации PostgreSQL 8.x

Thu, 7 Jun 2007 17:36:31 GMT

Перед вами набор простых правил настройки сервера PostgreSQL. Большая часть этих идей была высказана в оригинальной статье PostgreSQL Performance Checklist Джошем Беркусом (Josh Berkus); сотрудники компании "Постгресмен" добавили к этому листу ряд важных пунктов, адаптировав некоторые места под более актуальные версии PostgreSQL. Статья написана так, чтобы администратор баз данных мог в течение получаса оптимизировать PostgreSQL, усвоив основные принципы его настройки.

Пять основных принципов настройки PostgreSQL-сервера

Диски>Память>ЦПУ Если вы решили купить сервер под базу данных, лучше выбрать массив дисков с высокой производительностью, средний процессор и соответствующую память. Если ваш бюджет не позволяет вложиться в дисковый массив, лучше взять побольше памяти. Как и любая ACID-совместимая СУБД, PostgreSQL очень сильно зависит от скорости обмена данными, и редкое приложение, использующее Postgres, требует больше от процессора, чем от SCSI (хотя, бывают и такие). Это относится как к маленьким приложениям, так и к огромным, так что покупайте топовый процессор, только если кроме него хватит денег на дорогой RAID-контроллер из последней линейки хорошего производителя вроде LSI, 3ware или Areca и много дисков. (Важное замечание: в наши дни память уже не является такой дорогой, поэтому внимательно проанализируйте вашу ситуацию — если вы разрабатываете web-приложение, то вероятность того, что вам удастся добиться того, что большая часть ваших данных будет располагаться в RAM, достаточно высока. Поэтому не торопитесь, может быть, вам повезло и в вашем случае диски не являются узким местом.)
Много дисков == хорошо! Имея много дисков, PostgreSQL, как и многие операционные системы, разделяет запросы на чтение и запись в базу данных. Это сразу заметно для всех приложений, база данных которых не помещается в оперативную память. При том, что минимальный размер винчестера сейчас равен 72 Гб и можно попробовать обойтись одним диском или одной RAID 1 mirrored парой, используя 2, 4, 6 или даже 14 дисков, вы значительно повысите производительность. Ну, и, конечно же, SCSI дает гораздо больший выигрыш, чем IDE, даже с Serial ATA.
Отделите логи транзакций от базы данных Предположим, что вы уже потратили деньги на достойный массив дисков. Мало просто засунуть их в один RAID. Выделение для лога транзакций (pg_xlog) собственных дисковых ресурсов (массива или просто отдельного диска) дает как минимум 12% выигрыш для нагруженных систем. Это жизненно важно и для небольших серверов, особенно с медленными SCSI или IDE дисками: даже на машине с двумя дисками можно выселить лог транзакций на диск с операционной системой и получить при этом существенный выигрыш в производительности.
RAID 1+0/0+1>RAID 5 RAID 5 с тремя дисками уже стал эталоном неудачных бюджетных серверов. Это, вероятно, наихудшая комбинация для PostgreSQL: вы сможете получить не более 50% от той производительности, которая была бы у вас с одним SCSI диском. Если у вас массив из 2, 4 или 6 дисков, то лучше остановиться на RAID 1, или 1+0, или 0+1. Когда дисков больше 6, RAID 5 восстанавливает свои позиции, и выбирать конкретную схему RAID нужно уже в зависимости от вашего контроллера. Имейте в виду, что зачастую использование программного RAID более предпочтительно, особенно если в сервере установлен дешевый контроллер вроде встроенного от Adaptec (Важное замечание: стоит отметить, что дешевые RAID-контроллеры зачастую проигрывают программному RAID и это относится не только к Adaptec, но и к LSI, 3ware и другим.)
Приложения должны жить дружно Многие компании допускают одну и ту же ошибку: ставят на сервер вместе с PostgreSQL другие приложения, которые начинают бороться с ним за одни и те же ресурсы. Хуже того, бывает, что на одной машине стоит несколько СУБД. Они сражаются за пропусную способность винчестера и за дисковый кэш операционной системы. В итоге все СУБД работают плохо. Почти так же дело обстоит, если PostgreSQL работает на сервере документооборота или системы слежения за безопасностью, которая ведет активное журналирование. PostgreSQL может хорошо работать только вместе с приложениями, которые больше зависят от мощности процессора, чем от производительности дисков. Например, при достаточном количестве оперативной памяти, с PostgreSQL хорошо уживается веб-сервер от Apache.

Десять параметров, которые нужно менять в postgresql.conf

Количество параметров, которые появились в основном конфигурационном файле PostgreSQL, postgresql.conf, просто пугает. Даже те функции, которые были знакомы по предыдущим версиям, сменили свое название. Все это сделано для того, чтобы обеспечить администратору базы данных большую свободу, но к нововведениям нужно привыкнуть.

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

Замечание: если вы комментируете какой-либо параметр в postgresql.conf, это совсем не значит, что он принимает первоначальное значение по умолчанию. PostgreSQL будет помнить значение его последней настройки.

Соединения

listen_adresses: заменяет tcp_ip и virtual_hosts из PostgreSQL 7.4. По умолчанию, как правило, устанавливается разрешение только на соединение в пределах сервера через локальный сокет ("localhost"). Многие администраторы БД предпочитают указывать "*", чтобы PostgreSQL слушал все доступные сетевые интерфейсы для возможности (после добавления соответствующих настроек в файл pg_hba.conf) устанавливать соединение по сети.

max_connections: как и в более ранних версиях, нужно указать максимально количество возможных одновременных соединений, которое вам может понадобиться. Если задать большие значения, вам может понадобиться больше разделяемой памяти (shared_buffers). Так как ограничение на число соединений, как у ОС, так и у PostgreSQL может быть довольно большим, то имеет смысл группировать соединения. Например, для среднего однопроцессорного 32-битного linux-сервера уже 150 соединений будут вполне ощутимы, а 600 соединений будут пределом возможностей. Для более мощных серверов эти числа, конечно, больше.

Память

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

На выделенных серверах полезным объемом будет значение от 8 МБ до 2 ГБ. Объем может быть выше, если у вас большие активные порции базы данных, сложные запросы, большое число одновременных соединений, длительные транзакции, вам доступен большой объем оперативной памяти или большее количество процессоров. И, конечно же, не забываем об остальных приложениях. Выделив слишком много памяти для базы данных, мы можем получить ухудшение производительности. Вот несколько примеров, полученных на личном опыте и при тестировании:

Laptop, Celeron processor, 384MB RAM, база данных 25MB: shared_buffers 12 MB
Athlon server, 1GB RAM, база данных поддержки принятия решений 10GB: 200 MB
Quad PIII server, 4GB RAM, 40GB, 150 соединений, "тяжелые" транзакции: 1 GB
Quad Xeon server, 8GB RAM, 200GB, 300 соединений, "тяжелые" транзакции: 2 GB

Заметим, что увеличение числа shared_buffers и других параметров памяти потребует изменения настроек System V memory вашей операционной системы. Подробнее об этом можно прочитать в документации по PostgreSQL.

work_mem: ранее известное как sort_mem, было переименовано, так как сейчас определяет максимальное количество оперативной памяти, которое может выделить одна операция сортировки, агрегации и др. Это не разделяемая память, work_mem выделяется отдельно на каждую операцию (от одного до нескольких раз за один запрос). Разумное значение параметра определяется следующим образом: количество доступной оперативной памяти (после того, как из общего объема вычли память, требуемую для других приложений, и shared_buffers) делится на максимальное число одновременных запросов умноженное на среднее число операций в запросе, которые требуют памяти.

Для веб-приложений обычно устанавливают низкие значения work_mem, так как запросов обычно много, но они простые, обычно хватает от 512 до 2048 КБ. С другой стороны, приложения для поддержки принятия решений с сотнями строк в каждом запросе и десятками миллионов столбцов в таблицах фактов часто требуют work_mem порядка 500 МБ. Для баз данных, которые используются и так, и так, этот параметр можно устанавливать для каждого запроса индивидуально, используя настройки сессии.

maintenance_work_mem: предыдущее название в PostgreSQL 7.x vacuum_mem. Это объем памяти, который требуется PostgreSQL для VACUUM, ANALYZE, CREATE INDEX, и добавления внешних ключей. Чтобы операции выполнялись максимально быстро, нужно устанавливать этот параметр тем выше, чем больше размер таблиц в вашей базе данных. Неплохо бы устанавливать его значение от 50 до 75% размера вашей самой большой таблицы или индекса или, если точно определить невозможно, от 32 до 256 МБ.

Диск и журнал транзакций (WAL)

checkpoint_segments: определяет количество сегментов (каждый по 16 МБ) лога транзакций между контрольными точками. Этот параметр не имеет особого значения для базы данных, предназначенной преимущественно для чтения, но для баз данных со множеством транзакций увеличение этого параметра может оказаться жизненно необходимым. В зависимости от объема данных установите этот параметр в диапазоне от 12 до 256 сегментов и, если в логе появляются предупреждения (warning) о том, что контрольные точки происходят слишком часто, постепенно увеличивайте его. Место, требуемое на диске, вычисляется по формуле (checkpoint_segments * 2 + 1) * 16 МБ, так что убедитесь, что у вас достаточно свободного места. Например, если вы выставите значение 32, вам потребуется больше 1 ГБ дискового пространства.

max_fsm_pages: определяет размер реестра, в котором хранится информация о частично освобождённых страницах данных, готовых к заполнению новыми данными. При правильной настройке ускоряет VACUUM и избавляет от необходимости делать VACUUM FULL или REINDEX. Значение этого параметра нужно установить чуть больше, чем полное число страниц, которые могут быть затронуты операциями обновления или удаления между выполнением VACUUM. Чтобы определить это число, можно запустить VACUUM VERBOSE ANALYZE и выяснить общее число страниц, используемых базой данных. max_fsm_pages обычно требует немного памяти, так что на этом параметре лучше не экономить.

vacuum_cost_delay: Если у вас большие таблицы, и производится много одновременных операций записи, вам может пригодиться функция, которая уменьшает затраты на I/O для VACUUM, растягиваяя его по времени. Чтобы включить эту функциональность, нужно поднять значение vacuum_cost_delay выше 0. Используйте разумную задержку от 50 до 200 мс. Для более тонкой настройки повышайте vacuum_cost_page_hit и понижайте vacuum_cost_page_limit. Это ослабит влияние VACUUM, увеличив время его выполнения. В тестах с параллельными транзакциями Ян Вик (Jan Wieck) получил, что при значениях delay - 200, page_hit - 6 и предел - 100 вляние VACUUM уменьшилось более чем на 80%, но его длительность увеличилась втрое.

Планировщик запросов

Следующие настройки помогают планировщику запросов правильно оценивать стоимости различных операций и выбирать оптимальный план выполнения запроса. Существуют 2 глобальные настройки планировщика, на которые стоит обратить внимание:

effective_cache_size: указывает планировщику на размер самого большого объекта в базе данных, который теоретически может быть закеширован. На выделенном сервере имеет смысл выставлять effective_cache_size в 2/3 от всей оперативной памяти; на сервере с другими приложениями сначала нужно вычесть из всего объема RAM размер дискового кэша ОС и память, занятую остальными процессами.

random_page_cost: переменная, указывающая на условную стоимость индексного доступа к страницам данных. На серверах с быстрыми дисковыми массивами имеет смысл уменьшать изначальную настройку до 3.0, 2.5 или даже до 2.0. Если же активная часть вашей базы данных много больше размеров оперативной памяти, попробуйте поднять значение параметра. Можно подойти к выбору оптимального значения и со стороны производительности запросов. Если планировщик запросов чаще, чем необходимо, предпочитает последовательные просмотры (sequential scans) просмотрам с использованием индекса (index scans), понижайте значение. И наоборот, если планировщик выбирает просмотр по медленному индексу, когда не должен этого делать, настройку имеет смысл увеличить. После изменения тщательно тестируйте результаты на максимально широком наборе запросов. Никогда не опускайте значение random_page_cost ниже 2.0; если вам кажется, что random_page_cost нужно еще понижать, разумнее в этом случае менять настройки статистики планировщика.

Масштабирование PostgreSQL: готовые решения от Skype

Mon, 23 Apr 2007 00:00:00 GMT

Автор: Иван Золотухин

Совсем недавно компания Skype выложила в открытое пользование под лицензией BSD ряд своих наработок, анонсированных прошлым летом на конференции, посвященной 10-летию PostgreSQL. Эти решения позволяют полностью решить проблемы масштабирования и резервирования OLTP систем, а также организовать необходимую синхронизацию с OLAP базами данных, решив таким образом 2 самых основных проблемы, с которыми сталкиваются разработчики баз данных при построении высоконагруженных систем. В пресс-релизы об этом событии вошли лишь краткие описания продуктов от Skype, поэтому возникла необходимость описать более подробно те возможности, которые появились у разработчиков и администраторов баз данных PostgreSQL.

PL/Proxy

PL/Proxy представляет собой прокси-язык для удаленного вызова процедур и партицирования данных между разными базами. Основная идея его использования заключается в том, что появляется возможность вызывать функции, расположенные в удаленных базах, а также свободно работать с кластером баз данных (например, вызвать функцию на всех узлах кластера, или на случайном узле, или на каком-то одном определенном).

Чем PL/Proxy может быть полезен? Он существенно упрощает горизонтальное масштабирование системы. Становится удобным разделять таблицу с пользователями, например, по первой латинской букве имени -- на 26 узлов. При этом приложение, которое работает непосредственно с прокси-базой, ничего не будет замечать: запрос на авторизацию, например, сам будет направлен прокси-сервером на нужный узел. То есть администратор баз данных может проводить масштабирование системы практически независимо от разработчиков приложения.

PL/Proxy позволяет полностью решить проблемы масштабирования OLTP систем. В систему легко вводится резервирование с failover-ом не только по узлам, но и по самим прокси-серверам, каждый из которых работает со всеми узлами.

Несколько примеров от Skype

1. Простейший пример удаленного вызова функции. Соединяемся с dbname=users выполняем запрос SELECT * FROM get_user_email($1); на удаленной базе:

CREATE FUNCTION get_user_email(username text)
RETURNS text AS $$
    CONNECT 'dbname=users';
$$ LANGUAGE plproxy;

2. Пример с партицированием. Пользователи разделены по разным базам, номер партиции вычисляется функцией hashtext(username):

CREATE FUNCTION get_user_email(username text)
RETURNS text AS $$
    CLUSTER 'userdb';
    RUN ON hashtext(username);
$$ LANGUAGE plproxy;

3. Функции на прокси-сервере создаются с такой же сигнатурой, что и на удаленном сервере. В теле прокси-функции нужно определять лишь путь до удаленного сервера:

CREATE FUNCTION pwd_check(text, text) RETURNS boolean 
$$
  SELECT 1 FROM users WHERE name=$1 AND PWD=$2;
  IF FOUND THEN RETURN true;
  ELSE RETURN false;
$$ LANGUAGE plpgsql;


CREATE FUNCTION pwd_check(text, text) RETURNS boolean 
$$
  CLUSTER userdb_cluster;
  PARTITION BY hashtext($1);
$$ LANGUAGE plproxy;

4. Есть возможность выполнять произвольные SQL запросы:

CREATE FUNCTION get_user_location(text) RETURNS text AS $$
    CLUSTER 'userdb';
    RUN ON hashtext($1);
    SELECT email FROM users WHERE user = $1;
$$ LANGUAGE plproxy;

Недостатки и ограничения

все запросы и вызовы функций вызываются в autocommit-режиме на удаленных серверах
в теле функции разрешен только один SELECT; при необходимости нужно писать отдельную процедуру
при каждом вызове прокси-сервер стартует новое соединение к бакенд-серверу; в высоконагруженных системах целесообразно использовать менеджер для кеширования соединений к бакенд-серверам, для этой цели идеально подходит PgBouncer
изменение конфигурации кластера (количества партиций, например) требует перезапуска прокси-сервера

PgBouncer

PgBouncer представляет собой простой и быстрый менеджер соединений для PostgreSQL. Он поддерживает три режима управления соединениями:

Session Pooling. Наиболее "вежливый" режим. При начале сессии клиенту выделяется соединение с сервером; оно приписано ему в течение всей сессии и возвращается в пул только после отсоединения клиента.
Transaction Pooling. Клиент владеет соединением с бакендом только в течение транзакции. Когда PgBouncer замечает, что транзакция завершилась, он возвращает соединение назад в пул.
Statement Pooling. Наиболее агрессивный режим. Соединение с бакендом возвращается назад в пул сразу после завершения запроса. Транзакции с несколькими запросами в этом режиме не разрешены, так как они гарантировано будут отменены.

К достоинствам PgBouncer относится очень низкое потребление памяти (менее 2КБ на соединение по умолчанию), отсутствие привязки к одному серверу баз данных (может работать с разными хостами), возможность изменения большинства настроек без рестарта, а также возможность онлайн-перезапуска: PgBouncer сам перенесет открытые сокеты в новый процесс. Из недостатков стоит отметить разве что отсутствие поддержки протоколов старее V3, что требует использования в качестве бакенда сервера PostgreSQL версии новее, чем 7.4, но в настоящее время это уже не является серьезным ограничением. Для низкоуровневой работы с сокетами PgBouncer использует libevent.

WalMgr

Скрипт, написанный на python, максимально облегчающий процедуру разворачивания сервера с горячим бекапом на основе трансфера логов, а в случае отказа мастер-сервера -- быстрого переключения нагрузки на резервный сервер. Все весьма просто:

[ .. настраиваем небольшие конфиг файлы .. ]

master$ walmgr setup
master$ walmgr backup
slave$ walmgr restore

[ .. мастер-сервер отказал, переключаем нагрузку на резервный сервер с бекапом: ]

slave$ walmgr restore

Londiste

Представляет собой движок для организации репликации, написанный на языке python. Основные принципы: надежность и простота использования; из-за этого данное решение имеет меньше функциональности, чем Slony-I. Londiste использует в качестве транспортного механизма очередь PgQ (описание этого более чем интересного проекта остается за рамками данного мини-обзора, поскольку он представляет интерес скорее для низкоуровневых программистов баз данных, чем для конечных пользователей -- администраторов СУБД PostgreSQL). Отличительными особенностями решения являются:

возможность потабличной репликации
начальное копирование ничего не блокирует
возможность двухстороннего сравнения таблиц
простота установки

К недостаткам можно отнести:

отсутствие поддержки sequence делает невозможным поддержание failover-сервера актуальным (для этой цели нужно использовать WalMgr)
отсутствие поддержки каскадной репликации

Пример использования Londiste с инсталляцией:

$ londiste.py replic.ini provider install
$ londiste.py replic.ini subscriber install
$ londiste.py replic.ini replay -d
$ londiste.py replic.ini provider add users orders
$ londiste.py replic.ini subscriber add users

Ссылки

"Skype делится своими проектами", Новости PostgreSQL, Postgresmen
"PostgreSQL at Skype", доклад Skype на PostgreSQL Anniversary Summit 2006
Public Database Projects, Skype Developer Zone
PlProxy, Skype Developer Zone
SkyTools, Skype Developer Zone
PgBouncer, Skype Developer Zone
PlProxy, PgFoundry
SkyTools, PgFoundry
PgBouncer, PgFoundry

Any feedback is welcome at iz at sai dot msu dot ru
Apr 2007

Regexps in PostgreSQL / Регулярные выражения в PostgreSQL

Tue, 20 Jun 2006 02:29:35 GMT

Автор: Иван Золотухин

Маленькая заметка справочного характера на тему регулярных выражений в PostgreSQL

В PostgreSQL применяется 3 различных подхода к регулярным выражениям:

традиционный в SQL оператор LIKE
более новый оператор SIMILAR TO (добавлен в стандарте SQL:1999)
POSIX-совместимые регулярные выражения

Если предоставленных возможностей не хватает, предлагается использовать процедурные языки (например PL/Perl) и работать со строками оттуда. Также, важно отметить, что регулярные выражения не обладают чудесным быстродействием, поэтому не подходят для текстового поиска в больших объемах данных - для этой цели лучше использовать полнотекстовый поиск Tsearch2.

LIKE

Синтакс этого оператора в постгресе полностью традиционен: символ процента (%) соответствует любой строке в 0 или более символов, символ нижнего подчеркивания (_) матчит любой одиночный символ. Несколько примеров из документации должны полностью прояснить ситуацию:

test=# SELECT 'abc' LIKE 'abc';
 ?column? 
----------
 t
(1 row)

test=# SELECT 'abc' LIKE 'a%';
 ?column? 
----------
 t
(1 row)

test=# SELECT 'abc' LIKE '_b_';
 ?column? 
----------
 t
(1 row)

test=# SELECT 'abc' LIKE 'c';
 ?column? 
----------
 f
(1 row)

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

Для матча литералов % и _ их, как обычно, необходимо эскейпить символом обратного слеша (\).

Важное замечание! Так как символ обратного слеша (\) уже имеет особый смысл (он является escape-символом) в строковых литералах в Постгресе, его всегда тоже необходимо эскейпить опять же обратным слешем! Это приводит к конструкциям вида \\\\ для матча литерала обратного слеша в паттернах оператора LIKE. Для облегчения понимания можно представлять себе последовательную обработку регулярного выражения двумя различными парсерами: первый делает из строки настоящий регэксп, а второй - непосредственно парсит уже финальный вид регулярного выражения. Вы, однако, можете поменять escape-символ с помощью конструкции string LIKE pattern ESCAPE escape-character.

Для case-insensitive матча регулярным выражением в постгресе используется оператор ILIKE, что является одной из самых известных его gotchas.

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

~~ эквивалентен LIKE

~~* эквивалентен ILIKE

!~~ эквивалентен NOT LIKE

!~~* эквивалентен NOT ILIKE

SIMILAR TO

Этот оператор очень сильно похож на LIKE. Отличие лишь в том, что он интерпретирует регулярные выражения по стандарту SQL, который представляет собой любопытную смесь регэкспов нотации LIKE и общеупотребительных регэкспов.

Символы % и _ имеют точно такой же смысл, что и в LIKE, однако добавлены POSIX-подобные метасимволы:

Символ | обозначает выбор одной либо другой альтернативы
Символ * обозначает повторение предыдущего элемента 0 или более раз
Символ + обозначает повторение предыдущего элемента 1 или более раз
Круглый скобки () могут быть использованы для группировки элементов в один логический атом
Квадратные скобки [] определяют класс символов в точности так, как это сделано в POSIX-совместимых регулярных выражениях.

Важно помнить, что метасимволы ограниченного повторения (? и {...}) в SIMILAR TO не поддерживаются, хотя они и существуют в POSIX. Также символ точки (.) не является метасимволом.

Стандартные примеры из документации:

test=# SELECT 'abc' SIMILAR TO 'abc';
 ?column? 
----------
 t
(1 row)

test=# SELECT 'abc' SIMILAR TO 'a';
 ?column? 
----------
 f
(1 row)

test=# SELECT 'abc' SIMILAR TO '%(b|d)%';
 ?column? 
----------
 t
(1 row)

test=# SELECT 'abc' SIMILAR TO '(b|c)%';
 ?column? 
----------
 f
(1 row)

Также SQL-совместимые регулярные выражения поддерживаются функцией substring(string from pattern for escape-character), которая может извлекать по паттернам подстроки, ее описание смотрите в документации. Не забывайте, правда, что вызванная с двумя, а не с тремя параметрами, она будет работать в POSIX-режиме. Также следует помнить о том, что эскейп-символ можно менять при надобности: string SIMILAR TO pattern ESCAPE escape-character

POSIX

Да, это всем удобные и привычные регулярные выражения с понятным синтаксисом. Помните, однако, что эти возможности уникальны для Постгреса и отсутствуют (или реализованы в иной форме) в других СУБД.

Регэкспы в POSIX-нотации работают в PostgreSQL со следующими операторами:

~ осуществляет case-sensitive матч

~* осуществляет case-insensitive матч

!~ и !~* означают отрицание вышеуказанных операторов

Стандартные примеры:

test=# SELECT 'abc' ~ 'abc';
 ?column? 
----------
 t
(1 row)

test=# SELECT 'abc' ~ '^a';
 ?column? 
----------
 t
(1 row)

test=# SELECT 'abc' ~ '(b|d)';
 ?column? 
----------
 t
(1 row)

test=# SELECT 'abc' ~ '^(b|c)';
 ?column? 
----------
 f
(1 row)

Также, такие регэкспы могут быть использованы в функциях substring(string from pattern) и regexp_replace(source, pattern, replacement [, flags]).

Они поддерживают обычные символьные классы (как длинные названия вроде [[:digit:]], так и сокращения типа \d), группировки, метасимволы вроде точки, опережающие проверки, ограничения жадности и другие полезные операции.

Однако, не совсем привычны некоторые ограничения в регекспах:

\A соответствует началу строки

\m соответствует началу слова

\M соответствует концу слова

\y соответствует началу или концу слова

\Y соответствует только не началу и не концу слова

\Z соответствует концу строки

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

Например:

test=# SELECT '123' ~ '^\d{3}';
 ?column? 
----------
 f
(1 row)

test=# SELECT '123' ~ '^\\d{3}';
 ?column? 
----------
 t
(1 row)

Обратные ссылки (back references) на сгруппированные ранее подстроки доступны в функции regexp_replace как \i, где i является номером группировки.

Замечания

Необходимо сделать ряд важных замечаний о POSIX-регэкспах. Во-первых, PostgreSQL поддерживает несколько их "оттенков":

basic регулярные выражения (BREs), соответствующие редактору ed
extended регулярные выражения (EREs), которые приблизительно соответствуют egrep
advanced регулярные выражения (AREs), представляющие собой EREs с дополнительными не-POSIX возможностями, взятыми из языков Perl и Tcl.

Пользователь может выбирать как именно трактуются его POSIX-паттерны в сессии с помощью переменной regexp_flavor (по умолчанию переменная установлена в advanced):

test=# SHOW regex_flavor;
 regex_flavor 
--------------
 advanced
(1 row)

Используйте установку regexp_flavor в extended для обратной совместимости с PostgreSQL версии младше 7.4. Также стоит упомянуть о возможности менять поведение паттернов прямо run-time при помощи модификаторов регэкспов, ищите в документации или спрашивайте здесь.

Полезные ссылки

http://www.postgresql.org/docs/8.1/static/functions-matching.html - основная статья в документации PostgreSQL про регулярные выражения. По сути эта заметка является выжимкой из этой основной статьи.
http://www.oreillynet.com/pub/a/databases/2006/02/02/postgresq_regexes.html - довольно свежая статейка с множеством рецептов на ту же тему.

Any feedback is welcome at iz at sai dot msu dot ru
Jun 2006

C-Language functions for PostgreSQL / C-функции для PostgreSQL

Fri, 21 Oct 2005 02:15:40 GMT

Автор: Иван Золотухин

Интро
Пишем Set Returning Function
Простейшее использование Server Processing Interface
Отладка (debug) кода
Компиляция кода с помощью Makefile
Замечания

Интро

Данная статья содержит материалы, посвященные написанию на C функций для PostgreSQL - оказывается, делать это довольно легко, ну а бонусов вы получаете существенно больше, чем если бы вы писали всю ту же логику на процедурных языках. Скомпиленные в shared object функции затем можно будет загрузить в PostgreSQL и использовать по своему усмотрению как SQL команды, например.

Простейшие функции можно посмотреть и в мануале (заходите сюда только после изучения этого документа). Да, еще обязательно посмотрите на туториал с OSCON-2004 под названием "Power PostgreSQL: Extending Database with C".

Но если вы хотите чего-то большего, то мануал быстро перестанет вас устраивать. У меня лично с ходу во всем разобраться не очень получилось - так что эта статья посвящена таким, как я :)

Важное предупреждение 1: функции написаны без использования best practices, это всего лишь работающие черновики (даже нет обработки нулевого result set-а, который может вернуть SPI_execute, например). Автор особо не парился над внешним видом своего кода, поэтому нельзя считать его готовым продакшн-вариантом.

Важное предупреждение 2: Статья имеет вид, далекий от финального (см. Важное предупреждение 1), следовательно статья будет меняться. Я только что получил лист замечаний от Федора Сигаева (за что ему большое спасибо!), который знает о сишных функциях для Постгреса всё (в отличие от меня), так что я попытаюсь учесть его комментарии. To be continued, одним словом.

Пишем Set Returning Function

Итак, попробуем написать простейшую Set Returning Function (функцию, возвращающую сет значений, result set) - у нас она будет брать на вход инт с длиной сета и на выходе будет возвращать сет значений от единицы до заданного числа (вот так просто и тупо). Такая тупость выбрана не случайно - в функции нет абсолютно никаких наворотов кроме каркаса для демонстрации multicall-работы SRF. Напомню, что в стандартном случае, SRF функция работает в режиме value-per-call, то есть она за каждый вызов возвращает только одно значение и вызывается столько раз, сколько рядов у нас в result set-е. Между вызовами информация хранится в специальной структуре - контексте функции.

#include "postgres.h" // main include file (include always)
#include "fmgr.h" // "Function Manager" for V1 style
#include "funcapi.h" // to return set of rows

/* Version 1 Calling Conventions - так нужно писать все функции теперь */
PG_FUNCTION_INFO_V1(iz_test);

Datum 
iz_test(PG_FUNCTION_ARGS)
{
    /* Тот самый контекст функции */
    FuncCallContext *funcctx;
    /* Тоже нужно для multicall persistence */
    MemoryContext oldcontext;

    /* заходим сюда только в первом вызове функции */
    if (SRF_IS_FIRSTCALL()) {
        /* 
         * инициализация структуры-контекста фунции для 
         * хранения информации между вызовами
         */
        funcctx = SRF_FIRSTCALL_INIT();
        /*
         * переключаем контекст памяти на контекст, сохраняемый между вызовами                                                
         */        
        oldcontext = MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);
        /* 
         * говорим, что функцию нужно дергать столько раз, сколько указано
         * в ее первом аргументе
         */
        funcctx->max_calls = PG_GETARG_INT32(0);

        MemoryContextSwitchTo(oldcontext);
    }
    /* код, который исполняется при каждом вызове функции */
    funcctx = SRF_PERCALL_SETUP(); // контекст функции освежили
    if (funcctx->call_cntr < funcctx->max_calls) {
        /* 
         * Это, собственно, возвращение каждого item-а
         * Обратите внимание, что SRF_RETURN_NEXT в качестве аргументов 
         * принимает контекст функции для его обновления (хотя бы даже
         * счетчик передвинуть) и собственно то, что нужно вернуть, только
         * в виде Datum-а, который мы тут и делаем из инта
         */
        SRF_RETURN_NEXT(funcctx, Int32GetDatum(funcctx->call_cntr));
    } else {
        // так нужно все заканчивать
        SRF_RETURN_DONE(funcctx);
    }
}

Дальше вы должны сами скомпилить это дело в .so (см. ниже про компиляцию с помощью Makefile), положить Постгресу в нужное место и просто создать эту функцию:

CREATE OR REPLACE FUNCTION
        iz_test(integer) RETURNS setof int4 AS
        '/usr/lib/pgsql/c-func_test.so', 'iz_test'
LANGUAGE C
STRICT;

Потом все будет выглядеть приблизительно вот так:

test_db=# select iz_test(10);
 iz_test 
---------
       1
       2
       3
       4
       5
       6
       7
       8
       9
      10
(10 rows)

Time: 0.300 ms

Простейшее использование Server Processing Interface

Теперь попробуем использовать Server Processing Interface (SPI) для того, чтобы мы могли выполнять SQL-запросы. Каркас multicall функции трогать не будем, просто добавим туда работу со SPI_* функциями. Известные по первому примеру места я уже не комментирую.

#include "postgres.h" // main include file (include always)
#include "fmgr.h" // "Function Manager" for V1 style
#include "executor/spi.h" // Server Processing Interface
#include "funcapi.h" // to return set of rows and cope with tuples
#include <string.h>
#include <stdio.h>
#include <stdlib.h> // мы будем использовать atoi()

PG_FUNCTION_INFO_V1(get_level1_c);

Datum 
get_level1_c(PG_FUNCTION_ARGS)
{
    int32 pid = PG_GETARG_INT32(0);
    
    int spi_ret;
    char sql[100]; // не будем особо париться, пишем чтобы работало
    char *tupval;
    FuncCallContext *funcctx;
    MemoryContext oldcontext;
    Datum result;

    if (SRF_IS_FIRSTCALL()) {
        funcctx = SRF_FIRSTCALL_INIT();
        oldcontext = MemoryContextSwitchTo(funcctx->multi_call_memory_ctx);

        /* Готовимся выполнять запрос */
        SPI_connect(); // функция коннекта
        // непосредственно сама строка запроса
        snprintf(sql, sizeof(sql), "SELECT edge_pid2 FROM edge WHERE edge_pid1 = %d AND edge_pid2 <> %d", pid, pid);
        /* 
         * выполняем запрос. 0 в качестве третьего аргумента означает, 
         * что нужно обработать все туплы
         */
        spi_ret = SPI_execute(sql, true, 0);
        /* 
         * наша функция будет вызвана столько раз, сколько туплов в 
         * нашем результате 
         */
        funcctx->max_calls = SPI_processed;

        MemoryContextSwitchTo(oldcontext);
    }

    funcctx = SRF_PERCALL_SETUP();

    if (funcctx->call_cntr < funcctx->max_calls) {
        /*
         * Получаем строковое значение из текущего тупла
         * Обратите внимание, хотя мы выбирали в запросе всего одну колонку,
         * ее индекс равен 1, а не 0! Я лично потратил пару часов, чтобы это
         * понять, не повторяйте моих ошибок
         */
        tupval = SPI_getvalue(SPI_tuptable->vals[funcctx->call_cntr], SPI_tuptable->tupdesc, 1);
        // дальше тривиально - просто делаем инт из строки и в датум его
        result = Int32GetDatum(atoi(tupval));
        SRF_RETURN_NEXT(funcctx, result);
    } else {
        SPI_finish();
        SRF_RETURN_DONE(funcctx);
    }

}

Отладка (debug) кода

Отлаживать собственный код можно, пользуясь, например, макросом elog и выводя в виде NOTICE-ов содержание каких-либо переменных. Например:

elog(NOTICE, "My name is %s, I'm %d years old", "Vanya", 21);

По правильному замечанию Сергея Копосова, elog является устаревшим способом репорта об ошибках, правильнее использовать ereport, с помощью которого можно написать полностью эквивалентную конструкцию (подробнее читайте в документации):

ereport(NOTICE, (errmsg_internal("My name is %s, I'm %d years old", "Vanya", 21)));

Но если хочется делать все по-взрослому, то нужно использовать стандартный GNU debugger (gdb). Так как отлаживать мы будем процесс postmaster, нужно иметь привилегии пользователя, под которым он запущен. Итак, последовательность действий такова:

Стартуем какого-либо клиента, например psql
Из клиента выполняем SELECT pg_backend_pid(), узнавая тем самым pid процесса postmaster (это можно сделать и утилитой ps из командной строки)
Загружаем из клиента нашу динамическую библиотеку: LOAD '/usr/lib/pgsql/c-func_test.so'
В другой терминальной сессии под рутом, либо под хозяином postmaster-а (назовем его postgres, как это бывает обычно) стартуем дебаггер: gdb postgres server-process-id
Ставим breakpoint в нашей функции: (gdb) break my-function
Идем в назад в клиента и запускаем нашу функцию: SELECT my-function()
Нажимаем continue в дебаггере: (gdb) c или читаем help, если мы в нем первый раз оказались: (gdb) help

Компиляция кода с помощью Makefile

Для начала вам подойдет простейший Makefile:

# Makefile for building C-functions shared objects for PostgreSQL
# Author: IZ
# Date:   2005/10/20

SERVER_INCLUDES += -I $(shell pg_config --includedir)
SERVER_INCLUDES += -I $(shell pg_config --includedir-server)

CFLAGS += -g $(SERVER_INCLUDES)


.SUFFIXES: .so

.c.so:
    $(CC) $(CFLAGS) -fpic -c $<
    $(CC) $(CFLAGS) -shared -o $@ $(basename $<).o
    @echo Built!

clean:
    -rm -f *.o *.so *~ 2>/dev/null
    @echo Cleaned!

Затем просто запускаем make c-func_test.so и нам делается правильный со-шник в текущей директории. После этой процедуры уже можно делать LOAD в клиенте psql.

Важное примечание: уж не знаю по какой причине, но если я в качестве header-файлов беру те, что содержатся в pg_config --includedir-server, то есть из глобальных путей, при попытке загрузки so-шника в постгрес появляются сообщения вида undefined symbol: elog. Если при этом брать header-файлы из исходников постгреса, то есть указывать глобальные пути к ним, например, указывая в качестве ключа компилятору -I /home/iz/postgresql-8.0.2/src/include/, то определение elog-а найдется и все будет работать. Уж не знаю, почему при установке постгреса .h-файлы так неприятно обрезаются :(

Замечания

1. У вас не получится писать рекурсивные функции. Посмотрите на аргументы и возвращаемые значения, их типы и т.д. и догадайтесь сами, почему не получится.

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

Any feedback is welcome at iz at sai dot msu dot ru
Oct 2005

Что такое PostgreSQL?

Tue, 5 Apr 2005 23:56:22 GMT

Автор: Олег Бартунов

PostgreSQL - это свободно распространяемая объектно-реляционная система управления базами данных (ORDBMS), наиболее развитая из открытых СУБД в мире и являющаяся реальной альтернативой коммерческим базам данных.

PostgreSQL произносится как post-gress-Q-L (можно скачать mp3 файл postgresql.mp3), в разговоре часто употребляется postgres (пост-гресс). Также, употребляется сокращение pgsql (пэ-жэ-эс-ку-эль).

История развития PostgreSQL

Краткую историю PostgreSQL можно прочитать в документации, распространяемой с дистрибутивом или на сайте. Также, есть перевод на русский язык. Из нее следует, что современный проект PostgreSQL ведет происхождение из проекта POSTGRES, который разрабатывался под руководством Майкла Стоунбрейкера (Michael Stonebraker), профессора Калифорнийского университета в Беркли (UCB). Мне захотелось несколько подробнее показать взаимосвязи родословных баз данных, чтобы лучше понять место PostgreSQL среди основных игроков современного рынка баз данных.

Я попытался графически ( большая версия картинки откроется в новом окне) отобразить все наиболее заметные RDBMS и связи между ними и приблизительно привел даты их создания и конца. Пересечение объектов означает поглощение, при этом поглощаемый объект более бледен и не окантован. Знак доллара означает, что база данных является коммерческой. При этом, я основывался на информации, доступной в интернете, в частности в Wikipedia, в научных статьях, которые я читал и комментариях непосредственных пользователей БД, которые я получил после публикации этой картинки в интернете.

Надо сказать, что несмотря на то, что вся история реляционных баз данных насчитывает менее 4 десятков лет, многие факты из истории создания трактуются по-разному, даты не согласуются, а сами участники событий зачастую просто вольно трактуют прошлое.Здесь надо принимать во внимание тот факт, что базы данных - это большой бизнес, в котором развитие одних БД часто связано с концом других. Кроме того, БД в то время были предметом научных исследований, поэтому приоритетность работ является не последним аргументом при написании воспоминаний и интервью. Наверное, учитывая такую запутанность, премия ACM Software System Award #6 была присуждена одновременно двум соперничающим группам исследователей из IBM за работу над "System R" и Беркли - за INGRES, хотя Стоунбрейкер получил награду от ACM SIGMOD (сейчас это премия названа в честь Теда Кодда - автора реляционной теории баз данных) #1 в 1992 г., а Грей (Jim Gray, Microsoft) - #2 в 1993 году.

Итак, как следует из рисунка, видно две ветви развития баз данных - одна следует из "System R", которая разрабатывалась в IBM в начале 70-х, и другая из проекта "INGRES", которым руководил Стоунбрейкер приблизительно в тоже время. Эти два проекта начались как необходимость практического использования реляционной модели баз данных, разработанной Тедом Коддом (Ted Codd) из IBM в 1969,1970 годах. Надо помнить, что в то время имелось две альтернативные модели баз данных - сетевая и иерархическая, причем за ними стояли мощные силы - CODASYL Data Base Task Group (сетевая) и сама IBM с ее базой IMS (Information Management System с иерархической моделью данных). Немного в стороне стоит "Oracle", взлет которой во многом связан с коммерческим талантом Эллисона быть в нужном месте и в нужное время, как сказал Стоунбрейкер в своем интервью, хотя она вместе с IBM сыграла большую роль в создании и продвижении SQL.

"System R" сыграла большую роль в развитии реляционных баз данных, создании языка SQL (изначально SEQUEL, но из-за проблем с уже существующей торговой маркой пришлось выкинуть все гласные буквы). Из "System R" развилась SQL/DS и DB2. На самом деле, в IBM было еще несколько проектов, но они были чисто внутренними. Подробнее об этой ветви можно прочитать в весьма поучительном документе "The 1995 SQL Reunion: People, Projects, and Politics", также доступен русский перевод.

INGRES (или Ingres89), в отличие от "System R", вполне в духе Беркли развивалась как открытая база данных, коды которой распространялись на лентах практически бесплатно (оплачивались почтовые расходы и стоимость ленты). К 1980 году было распространено порядка 1000 копий. Название расшифровывается как "INteractive Graphics (and) REtrieval System" и совершенно случайно связано с французским художником Jean Auguste Dominique Ingres. Отличительной особенностью этой системы являлось то, что она разрабатывалась для операционной системы UNIX, которая работала на распространенных тогда PDP 11, что и предопределило ее популярность, в то время как "System R" работала только на больших и дорогих mainframe. Был разработан язык запросов QUEL, который, как писал Стоунбрейкер, похож на SEQUEL в том отношении, что программист свободен от знания о структуре данных и алгоритмах, что способствует значительной степени независимости от данных. Доступность INGRES и очень либеральная лицензия BSD, а также творческая деятельность, способствовали появлению большого количества реляционных баз данных, как показано на рисунке.

Стоунбрейкер лично способствовал их появлению, так он конце 70-х он организовал компанию Ingres Corporation (как он сам объясняет, ему пришлось на это пойти, так как Аризонский университет, потребовал поддержки), которая выпустила коммерческую версию Ingres, в 1994 году она была куплена CA (Computer Associates) и которая в 2004 году стала открытой как Ingres r3.

"NonStop SQL" компании Tandem Computers являлась модифицированной версией Ingres, которая эффективно работала на параллельных компьютерах и с распределенными данными. Она умела выполнять запросы параллельно и масштабировалась почти линейно с количеством процессоров. Ее авторами были выпускники из Беркли. Впоследствии, Tandem Computers была куплена компанией Compaq (2000 г.), а затем компанией HP.

Компания Sybase тоже была организована человеком из Беркли (Роберт Эпстейн) и на основе Ingres. Известно, что база данных компании Мaйкрософт "SQL Server" - это не что иное как база данных Sybase, которая была лицензирована для Windows NT. С 1993 года пути Sybase и Mirosoft разошлись и уже в 1995 году Sybase переименовывает свою базу данных в ASE (Adaptive Server Enterprise), а Microsoft стала продолжать развивать MS SQL.

Informix тоже возник из Ingres, но на это раз людьми не из Беркли, хотя Стоунбрейкер все-таки поработал в ней CEO после того, как Informix купила в 1995 году компанию Ilustra, чтобы прибавить себе объектно-реляционности и расширяемости (DataBlade), которую организовал все тот же Майкл Стоунбрейкер как результат коммерциализации Postgres в 1992 году. В 2001 году она была куплена IBM, которая приобретала немалое количество пользователей Informix и технологию. Таким образом, DB2 также приобрела немного объектно-реляционности.

Проект Postgres возник как результат осмысления ошибок Ingres и желания преодолеть ограниченность типов данных, за счет возможности определения новых типов данных. Работа над проектом началась в 1985 и в период 1985-1988 было опубликовано несколько статей, описывающих модель данных, язык запросов POSTQUEL, и хранилище Postgres. POSTGRES иногда еще относят к так называемым постреляционным СУБД. Ограниченность реляционной модели всегда являлась предметом критики, хотя все понимали, что это является следствием ее простоты и ее заслугой. Однако, проникновение компьютерных технологий во все сферы жизни требовали новых приложений, а от баз данных - поддержки новых типов данных и возможностей, например, поддержка наследования, создание и управление сложными объектами.

Еще при проектировании оригинальной версии POSTGRES основное внимание было уделено расширяемости и объектно-ориентированным возможностям. Уже тогда было ясна необходимость расширения функциональности DMBS от управления данными (data management) в сторону управления объектами (object management) и знаниями (knowledge management). При этом объектная функциональность позволит эффективно хранить и манипулировать нетрадиционными типами данных, а управление знаниями позволяет хранить и обеспечивать выполнения коллекции правил (rules), которые несут семантику приложения. Стоунбрейкер так и определил основную задачу POSTGRES как "обеспечить поддержку приложений, которые требуют службы управления данными, объектами и знаниями".

Одним из фундаментальным понятием POSTGRES является class. Class есть именованная коллекция экземпляров (instances) объектов. Каждый экземпляр имеет коллекцию именованных атрибутов и каждый атрибут имеет определенный тип. Классы могут быть трех типов - это основной класс, чьи экземпляры хранятся в базе данных, виртуальный (view), чьи экземпляры материализуются только при запросе (они поддерживаются системой управления правилами), и может быть версией другого (parent) класса.

Первая версия была выпущена в 1989 году, затем последовало еще несколько переписываний системы правил (rule system). Отметим, что коды Ingres и Postgres не имели ничего общего ! В POSTGRES была реализована поддержка таких типов как многомерные массивы, что уже шло в противоречие с реляционной моделью, timetravel - хранение версионности объектов (впоследствии, в версии 6.3 этот тип был удален, так как его поддержка требовала больших усилий, а версионность могла быть реализована на стороне приложения с помощью триггеров). В 1992 году была образована компания Illustra, а сам проект был закрыт в 1993 году выпуcком версии 4.2. Однако, несмотря на официальное закрытие проекта, открытый код и BSD лицензия сподвигли выпускников Беркли Andrew Yu и Jolly Chen в 1994 году взяться за его дальнейшее развитие. В 1995 году они заменили язык запросов POSTQUEL на общепринятый SQL, проект получил название Postgres95, изменилась нумерация версий, был создан веб сайт проекта и появились много новых пользователей (среди которых был и автор).

К 1996 году стало ясно, что название "Postgres95" не выдержит испытанием временем и было выбрано новое имя - "PostgreSQL", которое отражает связь с оригинальным проектом POSTGRES и приобретением SQL. Также, вернули старую нумерацию версий, таким образом новая версия стартовала как 6.0. В 1997 был предложен слон в качестве логотипа, сохранилось письмо в архивах рассылки -hackers за 3 марта 1997 года и последующая дискуссия. Слон был предложен Дэвидом Янгом в честь романа Агаты Кристи "Elephants can remember" (Слоны могут вспоминать). До этого, логотипом был бегущий леопард (ягуар). Проект стал большой и управление на себя взяла небольшая вначале группа инициативных пользователей и разработчиков, которая и получила название PGDG (PostgreSQL Global Development Group). Дальнейшее развитие проекта полностью документировано в документации и отражено в архивах списка рассылки -hackers.

Что есть PostgreSQL сегодня ?

На сегодняшний день выпущена версия PostgreSQL v8 (19 января 2005 года), которая является значительным событием в мире баз данных, так как количество новых возможностей добавленных в этой версии, позволяет говорить о возникновении интереса крупного бизнеса как в использовании, так и его продвижении. Так, крупнейшая компания в мире, Fujitsu поддержала работы над версией 8, выпустила коммерческий модуль Extended Storage Management. Либеральная BSD-лицензия позволяет коммерческим компаниям выпускать свои версии PostgreSQL под своим именем и осуществлять коммерческую поддержку. Например, компания Pervasive объявила о выпуске Pervasive Postgres.

PostgreSQL поддерживается на всех современных Unix системах (34 платформы), включая наиболее распространенные, такие как Linux, FreeBSD, NetBSD, OpenBSD, SunOS, Solaris, DUX, а также под Mac OS X. Начиная с версии 8.X PostgreSQL работает в "native" режиме под MS Windows NT, Win2000, WinXP, Win2003. Известно, что есть успешные попытки работать с PostgreSQL под Novell Netware 6 и OS2.

PostgreSQL неоднократно признавалась базой года, например, Linux New Media AWARD 2004, 2003 Editors' Choice Awards, 2004 Editors' Choice Awards.

PostgreSQL используется как полигон для исследований нового типа баз данных, ориентированных на работу с потоками данных - это проект TelegraphCQ, стартовавший в 2002 году в Беркли после успешного проекта Telegraph (название главной улицы в Беркли). Интересно, что компания Streambase, которая была основана Майком Стоунбрейкером в 2003 году (изначально "Grassy Brook") для коммерческого продвижения этого нового поколения баз данных, никаким образом не ассоциируется с проектом Беркли.

Основные возможности и функциональность

Полный список всех возможностей предоставляемых PostgreSQL и подробное описание можно найти в объемной документации (1300 страниц).

Надежность PostgreSQL является проверенным и доказанным фактом и обеспечивается следующими возможностями:
- полное соответствие принципам ACID - атомарность, непротиворечивость, изолированность, сохранность данных.
  - Atomicity - транзакция рассматривается как единая логическая единица, все ее изменения или сохраняются целиком, или полностью откатываются.
  - Consistency - транзакция переводит базу данных из одного непротиворечивого состояния (на момент старта транзакции) в другое непротиворечивое состояние (на момент завершения транзакции). Непротиворечивым считается состояние базы, когда выполняются все ограничения физической и логической целостности базы данных, при этом допускается нарушение ограничений целостности в течение транзакции, но на момент завершения все ограничения целостности, как физические, так и логические, должны быть соблюдены.
  - Isolation - изменения данных при конкурентных транзакциях изолированы друг от друга на основе системы версионности
  - Durability - PostgreSQL заботится о том, что результаты успешных транзакций гарантировано сохраняются на жесткий диск вне зависимости от сбоев аппаратуры.
- многоверсионность (Multiversion Concurrency Control,MVCC) используется для поддержания согласованности данных в конкурентных условиях, в то время как в традиционных базах данных используются блокировки. MVCC означает, что каждая транзакция видит копию данных (версию базы данных) на время начала транзакции, несмотря на то, что состояние базы могло уже измениться. Это защищает транзакцию от несогласованных изменений данных, которые могли быть вызваны (другой) конкурентной транзакцией, и обеспечивает изоляцию транзакций. Основной выигрыш от использования MVCC по сравнению с блокировкой заключается в том, что блокировка, которую ставит MVCC для чтения не конфликтует с блокировкой на запись, и поэтому чтение никогда не блокирует запись и наоборот. Конкурентные операции записи "мешают" друг другу только при работе с одной и той же записью.
- наличие Write Ahead Logging (WAL) - общепринятый механизм протоколирования всех транзакций, что позволяет восстановить систему после возможных сбоев. Основная идея WAL состоит в том, что все изменения должны записываться в файлы на диск только после того, как эти записи журнала, описывающие эти изменения будут и гарантировано записаны на диск. Это позволяет не сбрасывать страницы данных на диск после фиксации каждой транзакции, так как мы знаем и уверены, что сможем всегда восстановить базу данных используя журнал транзакций.
- Point in Time Recovery (PITR) - возможность восстановления базы данных (используя WAL) на любой момент в прошлом, что позволяет осуществлять непрерывное резервное копирование кластера PostgreSQL.
- Репликация также повышает надежность PostgreSQL. Существует несколько систем репликации, например, Slony (тестируется версия 1.1), который является свободным и самым используемым решением, поддерживает master-slaves репликацию. Ожидается, что Slony-II будет поддерживать multi-master режим.
- Целостность данных является сердцем PostgreSQL. Помимо MVCC, PostgreSQL поддерживает целостность данных на уровне схемы - это внешние ключи (foreign keys), ограничения (constraints).
- Модель развития PostgreSQL, которая абсолютно прозрачна для любого, так как все планы, проблемы и приоритеты открыто обсуждаются. Пользователи и разработчики находятся в постоянном диалоге через мэйлинг листы. Все предложения, патчи проходят тщательное тестирование до принятия их в программное дерево. Большое количество бета-тестеров способствует тестированию версии до релиза и вычищению мелких ошибок.
- Открытость кодов PostgreSQL означает их абсолютную доступность для любого, а либеральная BSD лицензия не накладывает никаких ограничений на использование кода.
Производительность PostgreSQL основывается на использовании индексов, интеллектуальном планировщике запросов, тонкой системы блокировок, системе управления буферами памяти и кэширования, превосходной масштабируемости при конкурентной работе.
- Поддержка индексов
  - Стандартные индексы - B-tree, hash, R-tree, GiST (обобщенное поисковое дерево)
  - Частичные индексы (partial indices) - можно создавать индекс по ограниченному подмножеству значений, например,
    create index idx_partial on foo (x) where x > 0;
  - Функциональные индексы (expressional indices) позволяют создавать индексы используя значения функции от параметра, например,
    create index idx_functional on foo ( length(x) );
- Планировщик запросов основывается на стоимости различных планов, учитывая множество факторов. Он предоставляет возможность пользователю отлаживать запросы и настраивать систему.
- Система блокировок поддерживает блокировки на нижнем уровне, что позволяет сохранять высокий уровень конкурентности при защите целостности данных. Блокировка поддерживается на уровне таблиц и записей. На нижнем уровне, блокировка для общих ресурсов оптимизирована под конкретную ОС и архитектуру.
- Управление буферами и кэширование используют сложные алгоритмы для поддержания эффективности использования выделенных ресурсов памяти.
- Tablespaces (табличные пространства) для управления хранения данных на уровне объектов, таких как базы данных, схемы, таблицы и индексы. Это позволяет гибко использовать дисковое пространство и повышает надежность, производительность, а также способствует масштабируемости системы.
- Масштабируемость основывается на описанных выше возможностях. Низкая требовательность PostgreSQL к ресурсам и гибкая система блокировок обеспечивают его шкалирование, в то время как индексы и управление буферами обеспечивают хорошую управляемость системы даже при высоких загрузках.
Расширяемость PostgreSQL означает, что пользователь может настраивать систему путем определения новых функций, агрегатов, типов,языков, индексов и операторов. Объектно-ориентированность PostgreSQL позволяет перенести логику приложения на уровень базы данных, что сильно упрощает разработку клиентов, так как вся бизнес логика находится в базе данных. Функции в PostgreSQL однозначно определяются названием, количеством и типами аргументов.
На рисунке приведена ER диаграмма системного каталога PostgreSQL, в котором заложены все сведения об объектах системы, операторах и методах доступа к ним. При инициализации PostgreSQL кластера (команда initdb) создаются две базы данных - template0 и template1, которые содержат предопределенный по умолчанию набор функциональностей. Любая другая база данных наследует template1, таким образом, часто используемые объекты и методы можно добавить в системный каталог template1.

PostgreSQL предоставляет командный интерфейс для работы с системным каталогом, с помощью которого можно не только получать информацию об объектах системы, но и создавать новые. Например, создавать базы данных с помощью CREATE DATABASE, новый домен - CREATE DOMAIN, оператор - CREATE OPERATOR, тип данных - CREATE TYPE.

Для создания нового типа данных и индексных методов доступа достаточно:
- Написать функции ввода/вывода и зарегистрировать их в системном каталоге с помощью CREATE FUNCTION
- Определить тип в системном каталоге с помощью CREATE TYPE
- Создать операторы для этого типа данных с помощью CREATE OPERATOR
- Написать функции сравнения и зарегистрировать их в системном каталоге с помощью CREATE FUNCTION
- Создать оператор по умолчанию, который будет использоваться для создания индекса по primary key - CREATE OPERATOR CLASS
Описанный сценарий использует существующих вид индекса. Для создания новых индексов надо использовать GiST.

Одной из примечательных особенностью PostgreSQL является обобщенное поисковое дерево или GiST (домашняя страница проекта), которое дает возможность специалистам в конкретной области знаний создавать специализированные типы данных и обеспечивает индексный доступ к ним не будучи экспертами в области баз данных. Аналогом GiST является технология DataBlade, которой сейчас владеет IBM (см. историческую справку выше). Идея GiST была придумана профессором Беркли Джозефом Хеллерстейном(Joseph M. Hellerstein) и опубликована в статье Generalized Search Trees for Database Systems. Оригинальная версия GiST была разработана в Беркли как патч к POSTGRES и позднее была инкорпорирована в PostgreSQL. Позже, в 2001 году код был сильно модифицирован для поддержки ключей переменной длины, много-атрибутных индексов и безопасной работы с NULL, также были исправлено несколько ошибок. К настоящему времени написано довольно много интересных расширений на основе GiST, в том числе:
- модуль полнотекстового поиска tsearch2. С версии 8.3 полнотекстовый поиск будет встроен в ядро PostgreSQL (см. Введение в полнотекстовый поиск).
- модуль для работы с иерархическими данными (tree-like) ltree
- модуль для работы с массивами целых чисел intarray
Дистрибутив PostgreSQL в поддиректории contrib/ содержит большое количество (около 80) так называемых контриб-модулей, реализующих разнообразную дополнительную функциональность, такую как, полнотекстовый поиск, работа с xml, функции математической статистики, поиск с ошибками, криптографические модули и т.д. Также, есть утилиты, облегчающие миграцию с mysql, oracle, для административных работ.
Поддержка SQL, кроме основных возможностей, присущих любой SQL базе данных, PostgreSQL поддерживает:
- Очень высокий уровень соответствия ANSI SQL 92, ANSI SQL 99 и ANSI SQL 2003. Подробнее можно прочитать в документации.
- Схемы, которые обеспечивают пространство имен на уровне SQL. Схемы содержат таблицы, в них можно определять типы данных, функции и операторы. Используя полное имя объекта можно одновременно работать с несколькими схемами. Схемы позволяют организовать базы данных совокупность нескольких логических частей, каждая их которых имеет свою политику доступа, типы данных. Для приложений, которые создают новые объекты в базе данных удобно и безопасно создавать отдельную схему (и включать ее в SEARCH_PATH) с тем, чтобы избежать возможной коллизии с именами объектов и удобством обновления приложения.
- Subqueries - подзапросы (subselects), полная поддержка SQL92. Подзапросы делают язык SQL более гибким и зачастую более эффективным.
- Outer Joins - внешние связки (LEFT,RIGHT, FULL)
- Rules - правила, согласно которым модифицируется исходный запрос. Главное отличие от триггеров состоит в том, что rule работает на уровне запроса и перед исполнением запроса, а триггер - это реакция системы на изменение данных, т.е. триггер запускается в процессе исполнения запроса для каждой измененной записи (PER ROW). Правила используются для указания системе, какие действия надо произвести при попытке обновления view.
- Views - представления, виртуальные таблицы. Реальных экземпляров этих таблиц не существуют, они материализуются только при запросе. Одним из основных предназначений 'view' является разделение прав доступа к родительским таблицам и к 'view, а также обеспечение постоянства пользовательского интерфейса при изменении родительских таблиц. Обновление 'view' (материализация) возможно в PostgreSQL с помощью pl/pgsql.
- Cursors - курсоры, позволяют уменьшить трафик между клиентом и сервером, а также память на клиенте, если требуется получить не весь результат запроса, а только его часть.
- Table Inheritance - наследование таблиц, позволяющее создавать объекты, которые наследуют структуру родительского объекта и добавлять свои специфические атрибуты. При этом наследуются значения атрибутов по умолчанию (DEFAULTS) и ограничение целостности (CONSTRAINTS). Поиск по родительской таблице автоматически включает поиск по дочерним объектам, при этом сохраняется возможность поиска только по ней (only). Наследование можно использовать для работы с очень большими таблицами для эмуляции partitioning.
- Prepared Statements (преподготовленные запросы) - это объекты, живущие на стороне сервера, которые представляют собой оригинальный запрос после команды PREPARE, который уже прошел стадии разбора запроса (parser), модификации запроса (rewriting rules) и создания плана выполнения запроса (planner), в результате чего, можно использовать команду EXECUTE, которая уже не требует прохождения этих стадий. Для сложных запросов это может быть большим выигрышем.
- Stored Procedures - серверные (хранимые) процедуры позволяют реализовывать бизнес логику приложения на стороне сервера. Кроме того, они позволяют сильно уменьшить трафик между клиентом и сервером.
- Savepoints(nested transactions) - в отличие от "плоских транзакций", которые не имеют промежуточных точек фиксации, использование savepoints позволяет отменять работу части транзакции, например вследствии ошибочно введенной команды, без влияния на оставшуюся часть транзакции. Это бывает очень полезно для транзакций, которые работают с большими объемами данных.
- Права доступа к объектам системы на основе системы привилегий. Владелец объекта или суперюзер может как разрешать доступ (GRANT), так и отменять (REVOKE).
- Система обмена сообщениями между процессами - LISTEN и NOTIFY позволяют организовывать событийную модель взаимодействия между клиентом и сервером (клиенту передается название события, назначенное командой notify и PID процесса).
- Триггеры позволяют управлять реакцией системы на изменение данных (INSERT,UPDATE,DELETE), как перед самой операцией (BEFORE), так и после (AFTER). Во время выполнения триггера доступны специальные переменные NEW (запись, которая будет вставлена или обновлена) и OLD (запись перед обновлением).
- Cluster table - упорядочивание записей таблицы на диске согласно индексу, что иногда за счет уменьшения доступа к диску ускоряет выполнение запроса.
Богатый набор типов данных PostgreSQL включает:
- Символьные типы (character(n)) как определено в стандарте SQL и тип text с практически неограниченной длиной.
- Numeric тип поддерживает произвольную точность, очень востребованную в научных и финансовых приложениях.
- Массивы согласно стандарту SQL:2003
- Большие объекты (Large Objects) позволяют хранить в базе данных бинарные данные размером до 2Gb
- Геометрические типы (point, line, circle,polygon, box,...) позволяют работать с пространственными данными на плоскости.
- ГИС (GIS) типы в PostgreSQL являются доказательством расширяемости PostgreSQL и позволяют эффективно работать с трехмерными данными. Подробности можно найти на сайте проекта PostGis.
- Сетевые типы (Network types) поддерживают типы данных inet для IPV4, IPV6, а также cidr (Classless Internet Domain Routing) блоки и macaddr
- Композитные типы (composite types) объединяют один или несколько элементарных типов и позволяют пользователям манипулировать со сложными объектами.
- Временные типы (timestamp, interval, date, time) реализованы с очень большой точностью
- Псевдотипы serial и bigserial позволяют организовать упорядоченную последовательность целых чисел (AUTO_INCREMENT у некоторых СУБД).
PostgreSQL имеет очень богатый набор встроенных функций и операторов для работы с данными, полный список которых можно посмотреть в документации.
Поддержка 25 различных наборов символов (charsets), включая ASCII, LATIN, WIN, KOI8 и UNICODE, а также поддержка locale, что позволяет корректно работать с данными на разных языках.
Поддержка NLS(Native Language Support) - документация, сообщения об ошибках доступны на различных языках, включая японский, немецкий, итальянский, французский, русский, испанский, португальский, словенский, словацкий и несколько диалектов китайского языков.
Интерфейсы в PostgreSQL реализованы для доступа к базе данных из ряда языков (C,C++,C#,python,perl,ruby,php,Lisp и другие) и методов доступа к данным (JDBC, ODBC).
Процедурные языки позволяют пользователям разрабатывать свои функции на стороне сервера, тем самым переносить логику приложения на сторону базы данных, используя языки программирования, отличные от встроенных SQL и C. К настоящему времени поддерживаются (включены в стандартный дистрибутив) PL/pgSQL, pl/Tcl, Pl/Perl и pl/Python. Кроме них, существует поддержка PHP, Java, Ruby, R, shell.
Простота использования всегда являлась важным фактором для разработчиков.
Утилита psql (входит в дистрибутив) предоставляет удобный интерфейс для работы с базой данных, содержит краткий справочник по SQL, облегчает ввод команд (используя стрелки для повтора и табулятор для расширения), поддерживает историю и буфер запросов, а также позволяет работать как в интерактивном режиме, так и потоковом режиме.

phpPgAdmin (лицензия GPL) представляет возможность с помощью веб браузера администрировать PostgreSQL кластер.

pgAdmin III (GNU Artistic license) предоставляет удобный интерфейс для работы с базами данных PostgreSQL и работает под Linux, FreeBSD и Windows 2000/XP.

PgEdit - программная среда для разработки приложений и SQL-редактор, доступна для Windows и Mac.
Безопасность данных также является важнейшим аспектом любой СУБД. В PostgreSQL она обеспечивается 4-мя уровнями безопасности:
- PostgreSQL нельзя запустить под привилегированным пользователем - системный контекст
- SSL,SSH шифрование трафика между клиентом и сервером - сетевой контекст
- сложная система аутентификации на уровне хоста или IP адреса/подсети. Система аутентификации поддерживает пароли, шифрованные пароли, Kerberos, IDENT и прочие системы, которые могут подключаться используя механизм подключаемых аутентификационных модулей.
- Детализированная система прав доступа ко всем объектам базы данных, которая совместно со схемой, обеспечивающая изоляцию названий объектов для каждого пользователя, PostgreSQL предоставляет богатую и гибкую инфраструктуру.

Некоторые пределы PostgreSQL

Название	Значение
Максимальный размер БД	Unlimited
Максимальный размер таблицы	32 TB
Максимальная длина записи	400Gb
Максимальный длина атрибута	1 GB
Максимальное количество записей в таблице	Unlimited
Максимальное количество атрибутов в таблице	250 - 1600 в зависимости от типа атрибута
Максимальное количество индексов на таблицу	Unlimited

Сводная таблица основных реляционных баз данных

За основу взяты данные из Wikipedia

Название	ASE	DB2	FireBird	InterBase	MS SQL	MySQL	Oracle	PostgreSQL
Лицензия	$$$	$$$	IPL²	$$$	$$$	GPL/$$$	$$$	BSD
ACID	Yes	Yes	Yes	Yes	Yes	Depends¹	Yes	Yes
Referential integrity	Yes	Yes	Yes	Yes	Yes	Depends¹	Yes	Yes
Transaction	Yes	Yes	Yes	Yes	Yes	Depends¹	Yes	Yes
Unicode	Yes	Yes	Yes	Yes	Yes	Yes	Yes	Yes
Schema	Yes	Yes	Yes	Yes	No⁵	No	Yes	Yes
Temporary table	No	Yes	No	Yes	Yes	Yes	Yes	Yes
View	Yes	Yes	Yes	Yes	Yes	No	Yes	Yes
Materialized view	No	Yes	No	No	No	No	Yes	No³
Expression index	No	No	No	No	No	No	Yes	Yes
Partial index	No	No	No	No	No	No	Yes	Yes
Inverted index	No	No	No	No	No	Yes	Yes	Yes⁶
Bitmap index	No	Yes	No	No	No	No	Yes	No
Domain	No	No	Yes	Yes	No	No	Yes	Yes
Cursor	Yes	Yes	Yes	Yes	Yes	No	Yes	Yes
User Defined Functions	Yes	Yes	Yes	Yes	Yes	No⁴	Yes	Yes
Trigger	Yes	Yes	Yes	Yes	Yes	No⁴	Yes	Yes
Stored procedure	Yes	Yes	Yes	Yes	Yes	No⁴	Yes	Yes
Tablespace	Yes	Yes	No	?	No⁵	No¹	Yes	Yes
Название	ASE	DB2	FireBird	InterBase	MS SQL	MySQL	Oracle	PostgreSQL

Замечания:

1 - для поддержки транзакций и ссылочной целостности требуется InnoDB (не является типом таблицы по умолчанию)
2 - Interbase Public License
3 - Materialized view (обновляемые представления) могут быть эмулированы на PL/pgSQL
4 - только в MySQL 5.0, которая является экспериментальной версией
5 - только в MS SQL Server 2005 (Yukon)
6 - GIN (Generalized Inverted Index) с версии 8.2

Что ожидается в будущих версиях

Полный список новых возможностей приведен в большом списке TODO, который уже много лет поддерживает Брюс Момжан (Bruce Momjian), однако приоритеты для версии 8.1 еще не определены, более того, пока не определена продолжительность цикла разработки. Пока можно достаточно уверенно утверждать, что в 8.1 версии, помимо исправлений ошибок и улучшения существующей функциональности или приведение синтаксиса к стандарту SQL, будут:

bitmap индексы (initial submit CVS)
интегрирование autovacuum в серверный процесс
Two phase commit JDBC driver
поддержка IN,OUT,INOUT параметров для pl/pgsql (CVS)
увеличение предела максимального количества аргументов у функции (100 по умолчанию) (CVS)
Оптимизация MIN,MAX за счет использования индексов (CVS)
Поддержка UTF-16
GiST Concurrency & Recovery ! (CVS)

Также, недавно проходило обсуждение о возможных планах о поддержке table partitioning, что сильно увеличивает производительность базы данных при работе с большими таблицами.

Новость:

Вышла версия 8.0.2, в которой, помимо исправления ошибок и изменения версии библиотеки libpq (ВНИМАНИЕ ! Все клиентские приложения, которые используют libpq, требуется пересобрать, например DBD::Pg), алгоритм кэширования страниц "ARC", которым владеет IBM, был заменен на другой, "патентно-чистый" алгоритм "2Q".

Поскольку история с заменой алгоритма "ARC" в PostgreSQL вызвала большой интерес и обсуждение в сети (а она связана с очень "горячей" темой выдачи и использования патентов на программное обеспечение), я остановлюсь подробнее на описании механизма кэширования (buffer management) в PostgreSQL. Я использовал архив обсуждений, оригинальные работы и статью Элейн Мустэйн (A. Elein Mustain) The Saga of the ARC Algorithm and Patent.

Управление буферами в PostgreSQL

Кэширование страниц, или сохранение прочитанных с диска страниц в памяти, очень важно для эффективной работы любой СУБД, так как времена доступа к диску и памяти отличаются на многие порядки. В идеале, мы хотим, чтобы все страницы, к которым происходит обращение, попадали в память, с тем, чтобы последующее ее использование не требовало обращения к диску. Однако, так как количество доступной памяти ограниченно, то возникает ситуация, когда требуется принимать решение, какую страницу надо освободить (заместить) для того, чтобы поместить в кэш новую страницу. Практически все коммерческие системы используют ту или иную вариацию LRU (Least Recently Used) алгоритма, в котором высвобождается та страница, к которой дольше всего не обращались. В чистом виде этот алгоритм не очень хорош для использования в СУБД в силу большой разнообразности последовательности запросов, например, не учитывает частоту обращения к странице, не защищен от "cache flooding", когда всего одно единичное последовательное чтение большого количества страниц (sequential scan) может заполнить кэш страницами, к которым может не быть больше обращения, т.е., к полной потере эффективности кэширования. Иногда, используют термин "scan-resistant", когда говорят, что хороший алгоритм должет быть устойчив по отношению к "cache flooding".

PostgreSQL использовал разновидность этого алгоритма, известную как LRU/K, реализованную Томом Лайном (Tom Lane). В этом алгоритме используется история K-последних обращений к странице (именно последних, что позволяет этому алгоритму адаптироваться к изменениям шаблона запросов, в отличие от LFU алгоритма), которая позволяет отличить популярные страницы от давно не используемых. Для этого строится упорядоченная очередь (priority queue) указателей на страницы в кэше на основе времени обращения к странице по правилу: если у страницы P1 K-тое обращение (предпоследнее, для наиболее важного случая K=2, LRU/2 ) является более свежим чем у P2, то P1 будет замещено после P2. Классический LRU алгоритм можно рассматривать как LRU/1, так как он использовал информацию только об одном (последнем) обращении к странице. Важным является не то, что произошло единичное обращение к странице, а то, насколько эта страница была популярна в течение некоторого времени. Однако, этот алгоритм требовал нетривиальной настройки и время на построение очереди растет логарифмически в зависимости от размера буфера.

ARC (Adaptive Replacement Cache) алгоритм был привлекателен тем, что он учитывал не только как часто страница была использована, но и насколько недавно это происходило и не сильно "нагружал" процессор, как это происходило с LRU/K алгоритмом. Он динамически поддерживает баланс между часто используемыми и недавно используемыми страницами. Этот алгоритм был реализован Яном Виком (Jan Wieck) для версии 7.5 (впоследствии 8.0), который впоследствии был несколько улучшен после статьи, описывающей CAR (Clock with Adaptive Replacement) алгоритм. Однако, незадолго (за два дня) до выхода PostgreSQL 8.0 было обнаружено (см. постинг Нейла Конвея (Neil Conway) и последующее обсуждение), что IBM подала заявку на алгоритм ARC еще в 2002 году. Так как было уже поздно что-либо менять было решено выпустить 8.0 версию как есть, а потом заняться решением проблемы. Несмотря на то, что IBM еще не получила патент на ARC алгоритм и то, что IBM имеет хорошую практику поддержки OSS проектов, и можно было надеяться на получения официального разрешения на его использование в PostgreSQL, как предлагали многие, было решено исследовать вопрос о действительном нарушение патента и выяснить возможность замены ARC алгоритма на "патентно-чистый" алгоритм.

Основным аргументов в пользу замены алгоритма было желание сохранить PostgreSQL доступным для "любого использования" согласно BSD лицензии, которая позволяет коммерческое использование PostgreSQL без каких-либо лицензионных отчислений. В начале февраля 2005 года Том Лэйн предложил измененную версию ARC алгоритма, близкую к 2Q и опубликованную в 1994 году задолго до ARC, и которая решала проблему "cache flooding" ("scan resistant") и не требовала больших изменений в коде (в основном удаление кода), которая и была реализована в версии 8.0.2. 2Q алгоритм (Two Queue) почти также эффективен как LRU/K, но проще, не требует настройки и быстрее. Он добивается этого тем, что хранит в основном буфере только "горячие" страницы, а не занимается очищением "холодных" страниц в основном буфере как LRU/2. Упрощенно алгоритм выглядит так: при первом обращении указатель на страницу помещается в очередь A1 (FIFO), и если во время второго обращения страница еще находилась в A1, то страница называется горячей и помещается в основной буфер, который уже контролируется как LRU очередь. Если к странице не обращались пока она была в A1, то страница, вероятно, "холодная" и 2Q алгоритм удаляет ее из буфера.

PGDG - PostgreSQL Global Development Group

PostgreSQL развивается силами международной группы разработчиков (PGDG), в которую входят как непосредственно программисты, так и те, кто отвечают за продвижение PostgreSQL (Public Relation), за поддержание серверов и сервисов, написание и перевод документации, всего на 2005 год насчитывается около 200 человек. Другими словами, PGDG - это сложившийся коллектив, который полностью самодостаточен и устойчив. Проект развивается по общепринятой среди открытых проектов схеме, когда приоритеты определяются реальными нуждами и возможностями. При этом, практикуется публичное обсуждение всех вопросов в списке рассылке, что практически исключает возможность неправильных и несогласованных решений.

Это относится и к тем предложениям, которые уже имеют или рассчитывают на финансовую поддержку коммерческих компаний.

Цикл разработки

Цикл работой над новой версией обычно длится 10-12 месяцев (сейчас ведется дискуссия о более коротком цикле 2-3 месяца) и состоит из нескольких этапов (упрощенная версия):

Обсуждение предложений в списке -hackers. На собственном опыте могу заверить, что это очень непростой процесс и плохо подготовленный proposal не пройдет. Учитываются много факторов - алгоритмы, структуры данных, совместимость с существующей архитектурой, совместимость с SQL и так далее.
После принятия решения о работе над новой версией в CVS открывается новая ветка и с этого момента все изменения, касающиеся новых возможностей, вносятся туда. Также, анализируются патчи, которые присылаются в список -patches. Все изменения протоколируются и доступны любому для рассмотрения (anonymous CVS, -commiters лист рассылки или через веб-интерфейс к CVS). Иногда, в процессе работы над новой версией вскрываются или исправляются старые ошибки, в этом случае, наиболее критические исправляются и в предыдущих версиях (backporting). По мере накопления таких исправлений принимается решение о выпуске новой стабильной версии, которая совместима со старой и не требует обновления хранилища. Например, 7.4.7 - является bugfix-ом стабильной версии 7.4.
В некоторый момент объявляется этап code freeze(замораживания кода), после которого в CVS не допускается новая функциональность, а только исправление или улучшение кода. Граница между новой функциональностью и улучшением кода не описана и иногда возникают разногласия на этот счет, к документации и расширениям (contribution modules в поддиректории contrib/) обычно относятся более либерально. Замечу, что все это время все CVS версия проходит непрерывное тестирование на большом количестве машин, под разными архитектурами, операционными системами и компиляторами. Все это стало возможно благодаря проекту pgbuildfarm, который является распределенной системой тестирования, объединяющая добровольцев, которые предоставляют свои машины для тестирования. Проверяется не только корректность сборки, но и, благодаря обширному набору тестов (regression test), и правильность работы. Текущий статус (всех поддерживаемых версий, не только CVS) можно посмотреть на этой странице. Исходные тексты CVS версии PostgreSQL проходят тестирование в OSDL что помогает в обнаружении систематических изменений производительности (в обе стороны), иногда такие обнаружения приводят к необходимости "размораживания кода". Начиная с версии 8 такие тестирования будут регулярно проводиться в OSDL STP и PLM (STP - Scalable Test Platform и PLM - Patch Lifecycle Manager).
После внутреннего тестирования "собирается" дистрибутив и объявляется выход бета версии, на тестирование и исправление ошибок отводится 1-3 месяца. Бета версия не рекомендуется для использования в продакшн проектах (production), но практика показала хорошее качество таких версий и многие начинают ее использовать ради апробирования новой функциональности. Как правило, окончательная версия совместима с бета-версией и не требует обновления хранилища. По мере исправления замеченных ошибок выпускаются новые бета-версии.
После исправления всех замеченных ошибок, выпускается релиз-кандидат, который уже практически ничем не отличается от окончательной версии, разве что не хватает документации и списка изменений.
В течении месяца выходит окончательная версия, которая анонсируется на главном веб-сайте проекта и его зеркалах, мэйлинг листах. Также, PR группа, которая к этому моменту подготовила анонсы на разных языках, распространяет их по всем ведущим сайтам и СМИ. Они принимают участие в конференциях, семинарах и прочих общественных мероприятиях.

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

Структура

Управляющий комитет (6 человек).
Принимает решение о планах развития и выпусках новых версий.
Заслуженные разработчики ( 2 человека ).
Бывшие члены управляющего комитета, которые отошли от участия в проекте.
Основные разработчики (23).
Разработчики (22)

Кроме PGDG, значительное участие в развитии PostgreSQL принимает некоммерческая организация "The PostgreSQL Foundation", созданная для продвижения и поддержки PostgreSQL. Сайт фонда находится по адресу www.thepostgresqlfoundation.org.

Спонсорская помощь на развитие PostgreSQL поступает как от частных лиц, так и от коммерческих компаний, которые:

принимают на работу членов PGDG
оплачивают разработку каких-либо новых возможностей
предоставляют услуги в виде хостинга или оплаты трафика
поддерживают публичные мероприятия PGDG
выделяют своих программистов на участие в разработке

Кроме того, некоторые разработки поддерживаются государственными фондами, например, Российский Фонд Фундаментальных Исследований.

Где используется

Если изначально POSTGRES использовался в основном в академических проектах для исследования алгоритмов баз данных, в университетах как отличная база для обучения, то сейчас PostgreSQL применяется практически повсеместно. Например, зоны .org, .info полностью обслуживаются PostgreSQL, известны многотерабайтные хранилища астрономических данных, Lycos, BASF. Из российских проектов, использующих PostgreSQL, наиболее известными является портал Рамблер, в разработке которого я принимал участие в 2000-2002 годах, федеральные порталы Минобразования.

Сообщество

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

Поддержка

Основной источник актуальной информации о PostgreSQL является его официальный сайт www.postgresql.org, который имеет зеркала по всему миру. На нем публикуются сведения о всех событиях (анонсы релизов, семинаров, конференций), поддерживается список ресурсов, относящихся к PostgreSQL.

Основная поддержка осуществляется через почтовую рассылку, архивы которой доступны через Web по адресам:

archives.postgresql.org
Архив pgsql-ru-general - русскоязычного списка рассылки,как подписаться.
www.pgsql.ru/db/mw

Как показала многолетняя практика, списки рассылок являются наиболее эффективным и очень полезным источником знаний, обмена мнениями и помощи в самых различных ситуациях. На март 2005 года зарегистрировано 32812 пользователей, которые когда-либо писали в мэйлинг лист.

Небольшая статистика списков рассылок PostgreSQL по данным www.pgsql.ru на 1 апреля 2005 года.

Первая 20-ка мэйлинг листов по количеству постингов	Распределение постингов по годам
name \| count ---------------------+-------- HACKERS \| 107696 GENERAL \| 93272 SQL \| 27574 COMMITTERS \| 21384 ADMIN \| 20397 PATCHES \| 17354 NOVICE \| 13772 BUGS \| 13700 MISC \| 13545 INTERFACES \| 13029 JDBC \| 12705 QUESTIONS \| 7865 ADVOCACY \| 6676 CYGWIN \| 6166 WWW \| 5636 PERFORMANCE \| 5359 ODBC \| 5182 PORTS \| 4769 DOCS \| 3991 PHP \| 3106	# \| Year ------------- 19355 \| 2005 68403 \| 2004 71884 \| 2003 61604 \| 2002 58072 \| 2001 38793 \| 2000 25258 \| 1999 16779 \| 1998 15315 \| 1997 612 \| 1996 7 \| 1995

Первая 20-ка мэйлинг листов
по количеству постингов

Распределение постингов по годам

         name        | count   
 ---------------------+--------  
  HACKERS            | 107696  
  GENERAL            |  93272  
  SQL                |  27574  
  COMMITTERS         |  21384  
  ADMIN              |  20397  
  PATCHES            |  17354  
  NOVICE             |  13772  
BUGS               |  13700
 MISC               |  13545 
INTERFACES         |  13029
JDBC               |  12705
QUESTIONS          |   7865
 ADVOCACY           |   6676 
CYGWIN             |   6166
WWW                |   5636
PERFORMANCE        |   5359
ODBC               |   5182
PORTS              |   4769
DOCS               |   3991
 PHP                |   3106

  #   | Year  
-------------  
19355 | 2005  
68403 | 2004  
71884 | 2003  
61604 | 2002  
58072 | 2001  
38793 | 2000  
25258 | 1999  
16779 | 1998  
  15315 | 1997    
612 | 1996
   7 | 1995

Поисковая система PGsearch (разработана при поддержке РФФИ и Дельта-Софт) предоставляет поиск по сайтам сообщества. На момент написания этой статьи проиндексировано 480000 страниц из 67 сайтов, индекс обновляется еженедельно.
Много полезной информации по PostgreSQL можно найти на сайтах
Документация на русском (переводы и оригинальные статьи) доступны на сайте русскоязычного сообщества http://www.linuxshare.ru/postgresql/.
Ответы на ваши вопросы можно найти в "PostgreSQL FAQ " (часто задаваемые вопросы):
- Оригинальная версия
- на русском языке
Дистрибутивы PostgreSQL доступны для скачивания с основного ftp-сервера проекта и его зеркал. Подробная информация доступна со страницы http://www.postgresql.org/download/. Кроме того, многие дистрибутивы Linux распространяются с бинарной версией PostgreSQL и обеспечивают поддержку обновлений. Для ознакомления с PostgreSQL можно скачать образ загрузочного CD (Live CD) - bittorent формат или в ISO формате. Информацию о том, как инсталлировать PostgreSQL под Mac OS X можно найти здесь. Инсталлятор для Win32 можно скачать с сайта проекта Pginstaller.
Коммерческая поддержка осуществляется рядом компаний, список которых доступен по адресу www.postgresql.org/support/. Также на российском сайте ведется список российских компаний, которые заявили о поддержке PostgreSQL.

Разработка

Для проектов, имеющих отношение к PostgreSQL, предоставляется возможность размещать их на специальных сайтах, поддерживаемые PGDG и предоставляющие практически все, необходимые для разработчиков, сервисы:

Заключение

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

Благодарности

Автор благодарит русскоязычное сообщество за критику и дополнения, Российский Фонд Фундаментальных Исследований (РФФИ) за поддержку гранта 05-07-90225-в.

Текст написан Олегом Бартуновым в 2005 году, поправки и комментарии приветствуются.

Краткая справка:

Олег Бартунов (основная специальность астроном, работает в ГАИШ МГУ) является членом PGDG (основной разработчик) с 1996 года, был в числе основателей компании "GreatBridge", является членом "The PostgreSQL Foundation". Помимо использования PostgreSQL в проектах (самые известные - этo портал Рамблер, Научная Сеть, Астронет), он в 1996 году добавил поддержку locale в PostgreSQL, затем совместно с Федором Сигаевым (компания Delta-Soft) занимался поддержкой и разработкой GiST в PostgreSQL, на основе которого были разработаны такие популярные модули как полнотекстовый поиск, работа с массивами, поиск с ошибкам, поддержка иерархических данных. Соавтор свободного полнотекстового поиска для PostgreSQL OpenFTS. Является автором и создателем (совместно с Федором Сигаевым) сайта pgsql.ru. Занимается продвижением PostgreSQL для использования в астрономии, в частности, для работы с очень большими астрономическими каталогами, проект pgSphere - хранение данных со сферическими координатами и индексные методы доступа к ним.