SQL-Ex blog

Автор: Klaus Aschenbrenner, The Linux Page Cache and PostgreSQL

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

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

Continue reading "Кэш страниц Linux и PostgreSQL"

Автор: Joe Celko, The VALUES clause or building tables out of nothing

Предложение VALUES, вероятно, одна из самых неправильно используемых возможностей в SQL. Если вы посмотрите на онлайн-форумы по SQL, вы увидите, что люди используют его как второе предложение в операторе вставки, но используют его для построения только одной строки за раз, например так:

BEGIN

INSERT INTO Zodiac (astro_sign, astro_start_date, astro_end_date)

 VALUES ('Aries', '2025-03-21', '2025-04-19');

INSERT INTO Zodiac (astro_sign, astro_start_date, astro_end_date)

 VALUES ('Taurus', '2025-04-20', '2025-05-20');

… 

INSERT INTO Zodiac (astro_sign, astro_start_date, astro_end_date)

 VALUES ('Pisces', '2023-05-19', '2026-03-20');

END;

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

Я думаю, люди пишут такой код, потому что именно так вы бы читали перфокарты. Каждая карта поступает в устройство чтения карт, буферизуется и записывается в порядке поступления на магнитную ленту или дисковый файл. Добро пожаловать в 1960-е! Перестаньте подражать старым языкам программирования, таким как FORTRAN или BASIC, в которых были операторы WRITE, помещающие по одной записи за раз в файл. Начните думать о работе с целыми множествами.

Continue reading "Предложение VALUES или создание таблиц из ничего"

Автор: Shane Borden, Do PostgreSQL Sub-Transactions Hurt Performance?

Краткий ответ всегда: «возможно». Однако в этой статье я надеюсь продемонстрировать, что создаёт подтранзакции и что происходит с использованием общих идентификаторов транзакций (XID), когда они вызываются. Я также покажу, как на производительность влияет большое количество подключений, создающих и потребляющих подтранзакции.

Continue reading "Вредят ли производительности подтранзакции в PostgreSQL?"

Автор: Klaus Aschenbrenner, Where is My Clustered Index in PostgreSQL?

Каждый специалист по SQL Server рано или поздно достигает точки, когда внутреннее устройство хранения перестаёт быть абстракцией. Вы узнаёте, что таблица — это не просто логический контейнер, а физическая структура, и эта структура определяется кластерным индексом. Строки находятся на листовом уровне B-дерева, ключ кластеризации определяет физический порядок, и каждый некластерный индекс в конечном итоге ссылается обратно на этот ключ. Как только эта модель укореняется, настройка производительности начинает казаться почти интуитивной. Сканирование диапазона ведёт себя предсказуемо, поиск по закладкам (bookmark lookups) обретает смысл, а фрагментация становится ожидаемым следствием того, как хранятся данные.

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

Правда же заключается в том, что в PostgreSQL не отсутствуют кластерные индексы. Он сознательно выбрал иную основу.

Continue reading "Где же мой кластерный индекс в PostgreSQL?"

Автор: Shinya Kato, Reducing row count estimation errors in PostgreSQL

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

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

Continue reading "Уменьшаем ошибки оценки количества строк в PostgreSQL"

Автор: Jobin Augustine, Importance of Tuning Checkpoint in PostgreSQL

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

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

Continue reading "Важность настройки контрольной точки в PostgreSQL"

Автор: Akhil Reddy Banappagari, Null and Empty String in Oracle vs SQL Server vs PostgreSQL

При планировании миграции баз данных в PostgreSQL именно мелочи часто становятся причиной самых серьёзных сбоев в рабочей среде. Одна из самых распространённых ловушек для разработчиков — это различная обработка значений NULL и пустых строк ('') в разных СУБД.

Хотя они могут казаться схожими концепциями, обозначающими отсутствие значения, то, как механизм базы данных их интерпретирует, может изменить результаты ваших запросов, нарушить уникальные ограничения или привести к сбоям загрузки данных. В этом руководстве мы сравним поведение Oracle, SQL Server и PostgreSQL, чтобы помочь вам избежать распространённых ошибок миграции.

Continue reading "Значение NULL и пустая строка в Oracle, SQL Server и PostgreSQL"

Автор: Warda Bibi, Unlocking High-Performance PostgreSQL: Key Memory Optimizations

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

Это руководство проведёт вас через два самых важных параметра памяти:

• shared_buffers


• work_mem

Continue reading "На пути к быстрому PostgreSQL: ключевые точки оптимизации памяти"

Автор: Andrei Lepikhov, 500 Milliseconds on Planning: How PostgreSQL Statistics Slowed Down a Query 20 Times Over

Запрос выполняется всего за 2 миллисекунды, но этап его планирования занимает 500 мс. База данных имеет разумный размер, запрос затрагивает 9 таблиц, а default_statistics_target установлен всего в 500. Откуда такое несоответствие?

Этот вопрос недавно был поднят в списке рассылки pgsql-performance, и расследование выявило несколько неожиданного виновника: статистика столбцов, хранящаяся в таблице pg_statistic PostgreSQL.

Continue reading "500 миллисекунд на планирование: как статистика PostgreSQL замедлила запрос в 20 раз"

Автор: Lætitia AVROT, Why Your HA Architecture is a Lie (And That's Okay)

Если бы Дарт Вейдер существовал и решил бы сделать с Землёй то же, что он сделал с Алдерааном, все потеряли бы данные.

Мне нравится эта цитата Роберта Хааса, потому что это отрезвляющая реальность, которая нужна всем нам. В мире баз данных нам постоянно продают мечту о «пяти девятках» (99,999% времени доступности) и «нулевой потере данных» (RPO=0). Мы тратим месяцы на построение сложных кластеров, чтобы достичь этого.

Давайте будем честными: это сказки. Красивые для воображения, но они не существуют в рабочей среде. Если планетарная лазерная пушка — или даже просто серьёзный сетевой обрыв — поразит ваш дата-центр, ваши «гарантии» исчезнут.

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

Continue reading "Почему ваша архитектура высокой доступности — это иллюзия (и это нормально)"

Автор: Semab Tariq, Unused Indexes In PostgreSQL: Risks, Detection, And Safe Removal

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

Из реального производственного опыта мы наблюдали, что хорошо спроектированные, целевые индексы могут улучшить производительность запросов в 5 и более раз, особенно на больших транзакционных таблицах.

Однако индексы не являются бесплатными.

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

Continue reading "Неиспользуемые индексы в PostgreSQL: риски, обнаружение и безопасное удаление"

Автор: Radim Marek, Introduction to Buffers in PostgreSQL

Работа над RegreSQL заставила меня уделить много внимания буферам. Если вы иногда работаете с PostgreSQL, то наверняка слышали о настройке shared_buffers и следовали старому доброму совету выставить его на уровне 1/4 от доступной оперативной памяти. Но после того как мы немного слишком увлеклись этой темой в недавнем выпуске Postgres FM, меня спросили, что к чему.

Буферы — одна из тех тем, которую легко забыть. И хотя они являются фундаментальным блоком архитектуры производительности PostgreSQL, большинство из нас воспринимает их как чёрный ящик. Эта статья попытается это изменить.

Continue reading "Введение в буферы PostgreSQL"

Автор: Chao Li, Understanding ALTER TABLE Behavior on Partitioned Tables in PostgreSQL

Секционированные таблицы — это базовая возможность PostgreSQL, но один аспект по-прежнему регулярно вызывает путаницу — даже у опытных пользователей:

Как именно ведёт себя команда ALTER TABLE, когда задействованы секции?

Распространяется ли операция на секции? Влияет ли она на будущие секции? Действительно ли ключевое слово ONLY делает то, что заявлено? Почему некоторые команды работают на родительской таблице, но не на секциях — или наоборот?

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

Эта статья обобщает систематическое исследование поведения ALTER TABLE для секционированных таблиц, превращая разрозненные правила в последовательную классификационную модель.

Continue reading "Поведение команды ALTER TABLE для секционированных таблиц в PostgreSQL"

Автор: Shinya Kato, 4 causes of table bloat in PostgreSQL and how to address them

Раздувание таблиц в PostgreSQL — это явление, при котором «мёртвые записи» (dead tuples), образовавшиеся в результате операций UPDATE или DELETE, не собираются процессом VACUUM, что приводит к неоправданному увеличению размеров файлов данных.

Чтобы VACUUM мог освободить мёртвые записи, должна быть гарантия, что эти записи «точно не могут быть использованы какими-либо активными на данный момент транзакциями». Если старые транзакции сохраняются по какой-либо причине, сборка мусора процессом VACUUM останавливается на этой точке.

В этой статье объясняются следующие четыре причины раздувания таблиц: как каждая проявляется, как определить коренную причину и как её устранить.

1. Длительные транзакции


2. Незавершённые подготовленные транзакции


3. Запросы на серверах-репликах с включённым параметром hot_standby_feedback


4. Задержка логической репликации

Continue reading "Четыре причины раздувания таблиц в PostgreSQL и как с этим бороться"

Автор: Haki Benita, Unconventional PostgreSQL Optimizations

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

В этой статье я представляю нестандартные методы оптимизации в PostgreSQL.

Continue reading "Нестандартная оптимизация PostgreSQL"