Постгрессовый планнер с памятью

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

Анализатор исторической нагрузки pg_profile/pgpro_pwr и его новые возможности

Речь пойдет о простом инструменте стратегического анализа исторической нагрузки. Расширение предназначено для поиска проблем производительности в базах данных Postgres. Расскажу о принципах работы расширения, его применимости, возможностях и развитии. У pg_profile появилась расширенная ветка pgpro_pwr, предназначенная для работы в дистрибутивах PostgresPro с расширенным набором статистик производительности. Покажу на простых примерах преимущества, доступные в базах PostgresPro Enterprise Edition и PostgresPro Standard Edition.

Как переносить данные из Oracle в PostgreSQL и обратно

Использование PostgreSQL стало обычным делом во множестве организаций. В большинстве случаев PostgreSQL устанавливают в дополнение к уже имеющимся СУБД Oracle, и довольно скоро возникает закономерный вопрос: как перебрасывать данные из Oracle в PostgreSQL и наоборот? Давайте перенесёмся в прошлое, в март 2001, когда вышло новое расширение SQL стандарта, определившее общие принципы создания API для управления внешними данными: SQL/MED (ISO/IEC 9075-9:2008). Сообщество PostgreSQL довольно быстро создало фреймворк для использования рекомендаций стандарта в виде так называемых обёрток сторонних данных (foreign data wrappers). Это случилось в 2011 с выходом PostgreSQL 9.1. С тех пор число обёрток сторонних данных постоянно растёт. Сегодня благодаря им PostgreSQL может интегрировать данные почти из любого внешнего источника, будь то обычные файлы, другие реляционные СУБД или даже неструктурированные данные. В рамках этого доклада мы рассмотрим обёртку сторонних данных для Oracle и то, как её можно использовать для получения данных из Oracle в PostgreSQL. Однако обратное тоже верно: данные из PostgreSQL также можно отправить в Oracle, и это может быть важно для соблюдения требований. Обещаю, что в докладе будет две части: слайды и много демонстраций.

Ускорение быстрого текстового поиска с помощью индекса RUM

Быстрый текстовый поиск в PostgreSQL существенно ускоряется, если использовать обратные составные индексы по лексемам внутри типа tsvector. Индекс RUM - это свободное расширение, основанное на индексе GIN. Оно индексирует не только лексемы, но и их положение в текстовом поле, а также включает дополнительную информацию - вес лексемы, это позволяет полнее поддерживать возможности tsvector.

До недавних пор запросы с весами лексем в индексе RUM требовали перепроверки по таблице. Моя модификация (2020) в разы ускоряет такие запросы, делая их index-only.

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