Обобщённое табличное выражение (Common Table Expression, CTE) — это первая возможность, к которой часто обращаются разработчики, выходя за рамки базового SQL, а зачастую и единственная. Вы пишете подзапрос после WITH, даёте ему имя и используете в остальной части запроса. Он существует только на время выполнения этого запроса.
Но популярность CTE обычно связана не столько с модернизацией кода, сколько с обещанием императивной логики. Для многих CTE выступает в роли простого для понимания средства от «страшных запросов» и способа навязать базе данных порядок выполнения. Многие пишут запросы так, как будто они говорят оптимизатору: «сначала сделай это, затем сделай то».
Это создаёт проблему. CTE обеспечивают декомпозицию запросов, рекурсию и многосоставные DDL. Планировщик обрабатывает их по-разному в зависимости от того, как вы их пишете и используете. Долгое время (до PostgreSQL 12) CTE служили барьером для оптимизации. Планировщик не мог проталкивать условия предикатов внутрь них, не мог использовать индексы на нижележащих таблицах. Он не мог сделать ничего, кроме как материализовать их и просканировать полученный результат.
PostgreSQL 12 изменил это. Теперь CTE могут быть встроены, материализованы или находиться в промежуточном состоянии, в зависимости от того, как вы их пишете.
PostgreSQL известна как одна из наиболее продвинутых реляционных баз данных с открытыми кодами, и одна из основных причин ее силы - оптимизатор запросов на основе стоимости.
Когда вы запускаете запрос, оптимизатор не выполняет его непосредственно. Он генерирует множество возможных планов выполнения и оценивает их стоимость. Выбирается план с самой низкой оценкой стоимости. Стоимость не измеряется в миллисекундах или циклах ЦП - она представляет собой абстрактные единицы, которые PostgreSQL использует для сравнения.
Понимание этих параметров стоимости в PostgreSQL является существенным для настройки производительности, особенно тогда, когда дело касается больших таблиц и сложных запросов.
В этой статье мы:
Создадим таблицу с 10 миллионами строк для имитации реальной рабочей нагрузки.
Создадим индексы, чтобы дать возможность PostgreSQL построить несколько планов выполнения.
Подробно разберем модель стоимости в PostgreSQL.
Покажем, как настройка параметров стоимости может изменить решение при выборе плана.
Большинство людей, работающих с PostgreSQL, в конечном итоге узнают две команды для настройки запросов: EXPLAIN и EXPLAIN ANALYZE.
EXPLAIN показывает выбранный планировщиком план выполнения, а EXPLAIN ANALYZE выполняет запрос и добавляет статистику времени выполнения. Для большинства задач настройки этого уже достаточно для получения большого объёма информации.
Но многие не осознают, что у EXPLAIN есть ещё несколько опций, которые могут значительно упростить устранение неполадок. В некоторых случаях они отвечают на вопросы, на которые EXPLAIN ANALYZE сам по себе ответить не может.
В этой статье мы рассмотрим некоторые из этих менее популярных опций.
Добро пожаловать в третью часть нашей серии по созданию высокодоступного кластера Postgres с помощью Patroni! Часть первая была полностью посвящена созданию DCS с использованием etcd для обеспечения критически важного уровня DCS для кластера, а часть вторая добавила Patroni и Postgres в программный стек. Хотя на этом этапе можно остановиться и использовать кластер как есть, есть ещё один компонент, который сделает его гораздо более функциональным в целом.
Новым соединениям нужен способ легко и надёжно достигать основного узла. Patroni предоставляет REST-интерфейс для опроса каждого узла о его состоянии, что делает его идеальным решением для любого программного обеспечения или уровня балансировки нагрузки, совместимого с HTTP-проверками. Часть третья посвящена добавлению HAProxy для выполнения этой роли, завершая кластер уровнем маршрутизации.
Надеюсь, у вас всё ещё есть три виртуальные машины, на которых вы установили etcd, Postgres и Patroni. Они нам понадобятся для финального этапа, так что если вы ещё не прошли шаги из частей первой и второй, вернитесь, когда будете готовы.
Обновления мажорных версий PostgreSQL — одна из тех задач, с которой регулярно приходится сталкиваться каждому администратору баз данных. Это рутинная операция, но она также полна мелких, потенциально опасных деталей, которые могут превратить простое окно обслуживания в инцидент. Выполнив сотни обновлений в разных средах за многие годы, я хочу поделиться комплексным, практическим руководством по обновлению с PostgreSQL 17 на 18, с особым вниманием к тому, что изменилось и что наконец-то улучшилось в самом процессе обновления.
Эта статья основана на моём докладе на PGConf.EU 2024, дополненном с учётом пути обновления 17→18 и значительных улучшений, появившихся в версии 18. В это время года мы обычно рекомендуем нашим клиентам обновляться: текущий релиз 18.3 достаточно стабилен.
Хотя мне нравится использовать SQL Server, есть несколько вещей, для которых лучше подходят другие инструменты. Например, вычисление скользящего среднего или накопительных итогов зачастую проще выполнить с помощью таких инструментов, как Power BI или Excel. Это связано с тем, что Microsoft разрабатывала эти программы, имея в виду подобную функциональность. Недавно мы оптимизировали сложный запрос скользящего среднего, написанный для SQL Server 2008R2. Сюрприз! В SQL Server нет встроенной функции для вычисления скользящего среднего. Но не беспокойтесь, я покажу вам, как это сделать.
В этой статье я рассмотрю два метода для создания скользящего среднего в SQL Server. Мы начнем со старого и менее производительного способа, который присутствовал в нашей производственной системе. Кто знает, может быть вы все еще используете устаревшую версию SQL Server. Затем я покажу современный способ с использованием оконных функций и то, как добавление индекса, все меняет. К концу статьи вы будете готовы, чтобы справиться с этим скользящим средним в следующий раз, когда это кому-то понадобится, а не просто скажете: "Используй Excel".
Высокая доступность для PostgreSQL часто рассматривается как единое, большое, драматичное решение: «Делаем мы HA или нет?»
Такой подход толкает команды к двум крайностям:
«геройская архитектура», которая стоит дорого и всё равно вызывает напряжение при эксплуатации, или
минималистичная архитектура, которую все надеются, что будет просто продолжать работать.
Более спокойный способ проектирования — рассматривать HA и аварийное восстановление (DR) как слои. Вы начинаете с базового уровня, а затем добавляете конкретные возможности только тогда, когда ваши RPO/RTO и бюджет их оправдывают.
Давайте пройдём по слоям от «одного основного узла» до «многосайтовой готовности к аварийному восстановлению».
Предыдущая статья из цикла PG Phriday была посвящена архитектуре кластера Patroni — как и почему он устроен именно так. На этот раз речь пойдёт о непосредственном построении такого кластера. Я часто слышал, что эксплуатация Postgres может пугать, а Patroni находится на уровень выше. Что ж, со вторым я спорить не буду, но я могу хотя бы попытаться облегчить некоторые трудности.
Чтобы избежать ошеломляющего потока информации из двадцати страниц инструкций, я разбил эту статью на серию из трёх частей по следующему принципу:
Etcd
Postgres и Patroni
HAProxy
Это позволит описать каждый из трёх уровней, представляющих полный стек Patroni, и создаст удобный справочный материал для каждого из них.
Чтобы понять, как PostgreSQL сканирует данные, сначала нужно понять, как PostgreSQL их хранит.
Таблица хранится как набор 8-килобайтных страниц (по умолчанию) на диске. Каждая страница имеет заголовок, массив указателей на элементы (также называемых линейными указателями) и сами данные кортежей, растущие снизу вверх. Каждый кортеж имеет свой собственный заголовок, содержащий информацию о видимости: xmin, xmax, cmin/cmax и биты infomask.
Существуют различные способы, которыми PostgreSQL может читать данные с диска. В зависимости от запроса и доступных индексов он может выбрать одну из нескольких стратегий сканирования:
Последовательное сканирование (Sequential Scan)
Индексное сканирование (Index Scan)
Сканирование только индекса (Index-Only Scan)
Сканирование по битовой карте (Bitmap Index Scan)
В этой статье мы рассмотрим каждый из этих типов сканирования по отдельности.
Настройка производительности в PostgreSQL часто сводится к единственному навыку: умению читать планы выполнения. Команда PostgreSQL EXPLAIN ANALYZE - главный инструмент для этого. Она показывает не только то, как выполняется запрос, но и то, чего ожидал оптимизатор PostgreSQL, и что произошло на самом деле.
При просмотре плана выполнения вы всегда должны задать себе два больших вопроса:
Оправданы ли временные параметры, указанные в выводе команды EXPLAIN ANALYZE, для данного запроса?
В каком месте происходит внезапный скачок времени выполнения?
