PostgreSQL 8.

3
Николай Самохвалов (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.