SQL-Ex blog

Автор: Shaun Thomas, How Patroni Brings High Availability to Postgres

Давайте признаем: существует множество инструментов высокой доступности (High Availability) для управления кластерами Postgres. Этот ландшафт эволюционировал на протяжении десятилетий, достигнув своего нынешнего состояния, и в сообществе царит немалая путаница. Будь то Reddit, списки рассылки Postgres, Slack, Discord, IRC, доклады на конференциях или любые другие площадки, один из самых частых вопросов, которые мне задают: «Как сделать Postgres отказоустойчивым?»

Где-то с 2017 года мой ответ неизменен: «Просто используйте Patroni». Если только в экосистеме Postgres не произойдёт что-то чудесное, этот ответ вряд ли изменится. Но почему? Что делает Patroni «окончательным ответом», когда речь заходит о Postgres и высокой доступности? Это во многом связано с тем, как Patroni выполняет свою работу, и именно это мы и рассмотрим в данной статье.

Слон в посудной лавке

Сам по себе Postgres не является кластером в том смысле, который большинство людей вкладывает в это слово. Они могут представлять себе сложную массу взаимосвязанных серверов, яростно моргающих лампочками друг на друга, осведомлённых о каждом вычислении, совершаемом другими, и готовых взять на себя управление в случае сбоя одного из них. В реальности же «официальное» использование слова «кластер» в мире Postgres означает просто одну или несколько баз данных, связанных с одним экземпляром Postgres. Это прямо указано в документации по Creating a Database Cluster.

«A database cluster is a collection of databases that is managed by a single instance of a running database server».

Концепция взаимодействия нескольких таких экземпляров была настолько чужда Postgres, что даже не существовала до выхода версии 9.0, которая в 2010 году представила горячие резервные серверы (Hot Standbys) и потоковую репликацию. А как работают горячие резервные экземпляры? Так же, как и основной узел: они применяют страницы WAL к файлам кучи. Эти страницы WAL могут поступать из архивированных файлов WAL или передаваться потоком с основного сервера, но по сути это всё ещё непрерывное восстановление после сбоя под другим именем.

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

Конечно же, каждый узел должен заботиться о том, что другие узлы существуют! Именно так и родился каждый инструмент высокой доступности для Postgres. Slony и PgPool-II были, вероятно, первыми из них, использование Pacemaker и Corosync всегда было популярно в ранние дни, затем появились Bucardo, repmgr и EFM. Это лишь наиболее примечательные примеры, известные большинству сообщества.

Но после первоначального выпуска Patroni произошла забавная вещь: неумолимый поток инструментов высокой доступности для Postgres внезапно прекратился. Все сразу поняли, что в нём есть что-то, что кардинально отличает его от предшественников. Давайте поговорим о том, почему.

Продолжить чтение "Как Patroni обеспечивает высокую доступность PostgreSQL"

Пересказ статьи Aaron Bertrand. Common SQL Server Problems: Invalid Length

Это еще одна часть моей серии, представляющей общие проблемы в SQL Server. Сейчас мы поговорим о самой распространенной ошибке: invalid length (неверная длина).

Что означает ошибка invalid length в SQL Server?

Msg 537, Level 16, State 3

Invalid length parameter passed to the LEFT or SUBSTRING function.

Как показано выше, ошибка invalid length возникает, когда вы передаете некорректный или неожиданный параметр в строковую функцию. Например:

DECLARE @FirstName nvarchar(32) = N'frank';

SELECT LEFT(@FirstName, -1);

Продолжить чтение "Общие проблемы в SQL Server: Invalid Length"

Посетительниц сайта поздравляем с наступающим праздником 8 Марта! Желаем здоровья, счастья и вечной красоты!

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

§ Популярные темы недели на форуме

Топик		Сообщений	Просмотров
 Certification		9		12
 55 (DML)		4		5
 59 (DML)		3		4
 51 (Learn)		3		9
 56 (DML)		2		2

Продолжить чтение "Новости за 2026-02-28 - 2026-03-06"

Автор: Radim Marek: PostgreSQL Statistics: Why queries run slow

Каждый запрос начинается с плана. Каждый медленный запрос, вероятно, начинается с плохого плана. И чаще всего виновата статистика. Но как это работает на самом деле? PostgreSQL не выполняет запрос, чтобы узнать ответ — он оценивает стоимость. Он считывает предварительно вычисленные данные из pg_class и pg_statistic и выполняет расчёты, чтобы найти самый дешёвый путь к вашим данным.

В идеальном сценарии считанные числа точны, и вы получаете ожидаемый план. Но когда они устаревают, ситуация выходит из-под контроля. Планировщик оценивает 500 строк, планирует вложенный цикл (nested loop), а натыкается на 25 000. То, что казалось оптимальным планом, превращается в каскадный сбой.

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

В этой статье мы углубимся в два каталога, от которых зависит планировщик, поймём, что именно ANALYZE получает для вас из таблицы с 30 000 строк, и увидим, как эти числа определяют, будет ли ваш запрос выполняться миллисекунды или минуты.

Продолжить чтение "Статистика в PostgreSQL: Почему запросы выполняются медленно"

Пересказ статьи Chandan Shukla. UNLOGGED Tables in PostgreSQL When Speed Matters More Than Durability

Введение

Каждая реляционная база данных живет и умирает благодаря своему журналу транзакций. В SQL Server это файл журнала транзакций, в PostgreSQL это WAL (Write-Ahead Log - записывай сначала в журнал). Это работающее сердце, которое гарантирует надежность хранения, восстановление и репликацию. Без журнала вы не смогли бы обеспечить согласованность после сбоя, восстановить базу к определенному моменту времени или иметь надежные реплики.

Поэтому идея отказа от журнализации звучит почти безумно. Почему кому-то в здравом уме захочется избежать журнализации?

PostgreSQL дает вам именно такую возможность посредством таблиц UNLOGGED (нежурнализируемых). Это функция, которая меняет сценарий: таблица по-прежнему сохраняется на диске, но ее записи не попадают в WAL. Это означает существенно меньше накладных расходов, зачастую значительно более быстрые массовые операции, но при большом недостатке - ненадежность при сбоях базы данных.

Для администраторов SQL Server это кажется странным. У нас нет подобной функции «один в один». Вы можете подумать о BULK INSERT с минимальной журнализацией, временных таблицах в tempdb или даже об оптимизированных для памяти таблицах SCHEMA_ONLY. Каждый из этих случаев имеет кусочек от поведения UNLOGGED, но не все целиком.

В этой статье мы подробно рассмотрим таблицы UNLOGGED, зачем они нужны, как их можно использовать и о том, что позволяет отнести их к категории «специальных инструментов».

Продолжить чтение "Таблицы UNLOGGED в PostgreSQL: когда скорость важнее надежности"

Пересказ статьи SQLPals. Set Theory vs. Batch Mode in SQL Server

Не так давно коллега был в совершенном шоке, когда впервые услышал о возможности пакетного режима в SQL Server. Его мгновенной реакцией было: "Стой, но SQL основан на теории множеств. Не означает ли это, что он уже все обрабатывает как множество, а не построчно?"

Это действительно довольно общее представление, и на первый взгляд это имеет смысл. Кроме того, люди часто представляют силу реляционных баз данных в том, что они "обрабатывают множества данных за один прием". Однако есть нюансы. Давайте проясним ситуацию. Продолжить чтение "Теория множеств и пакетный режим в SQL Server"

Автор: Tomas Vondra, The real cost of random I/O

Параметр random_page_cost был введён около 25 лет назад, и с самого начала его значение по умолчанию установлено как 4.0. С тех пор хранилища сильно изменились, как и код Postgres. Вполне вероятно, что значение по умолчание уже не совсем соответствует реальности. Но какое значение следует использовать вместо него? Флеш-память гораздо лучше справляется с произвольным вводом-выводом, так что, возможно, стоит уменьшить значение по умолчанию? Некоторые источники заходят так далеко, что рекомендуют устанавливать его в 1.0, как и seq_page_cost. Верна ли эта интуиция?

Продолжить чтение "Реальная стоимость произвольного ввода-вывода PostgreSQL"

§ Очередная задача DML от selber опубликована под номером 59 (оценка сложности 2 балла).

§ Лидеры недели

	Участник		w_sel	all_sel	select	dml	Всего	Рейтинг
 Kad V.Y.  (s108)              	19	34	31	0	31	1436
 Новиков С.В.  (@Ser589QA)     	8	119	24	0	24	196
 Кайкова И.В.  (ira_kay)       	8	36	17	0	17	1373
 Заикин А.И.  (Fenrigrel)      	10	31	15	0	15	1549
 fioletovaya  (fioletovaya2)   	6	133	10	0	10	179
 Odnokurtsev  (AlFochino)      	4	37	10	0	10	1824
 Корсаков  (Wallen)            	4	4	7	0	7	6913
 Бадахьян С. (wamp.j)          	5	5	6	0	6	7226
 Burmenskiy D.O.  (dnlbrm)     	4	13	5	0	5	5511
 Zaichenko M.E.  (Makson4ikppcp	4	4	5	0	5	7822
 Саркисьян Г. (gennadi_s)      	1	206	4	0	4	15
 Равчеев  (Nikitiwe)           	3	3	4	0	4	8483

Продолжить чтение "Новости за 2026-02-21 - 2026-02-27"

Автор: Radim Marek, Radim Marek: Inside PostgreSQL's 8KB Page

Если вы читали предыдущую статью о буферах, вы уже знаете, что PostgreSQL, возможно, не обязательно заботится о ваших строках. Вы можете вставлять профиль пользователя или извлекать платёжные реквизиты, но всё, с чем работает Postgres — это блоки данных. Если быть точным, блоки по 8КБ. Вам нужно получить одну крошечную строку? PostgreSQL тащит с диска целую страницу размером 8192 байта, только чтобы отдать её вам. Вы обновляете один единственный булев флаг? То же самое. 8КБ-страница является АТОМАРНОЙ единицей ввода-вывода.

Но простого знания о существовании этих страниц недостаточно. Чтобы понять, почему база данных ведёт себя так, а не иначе, нужно понять, как она работает. Каждый раз, когда вы выполняете INSERT, PostgreSQL должен выяснить, как поместить его в одну из этих 8192-байтовых страниц.

Пул буферов кэширует их, журнал упреждающей записи (WAL) защищает их, а VACUUM очищает их. Глубокое погружение во внутреннее устройство хранилища PostgreSQL начинается с понимания того, что происходит внутри этих 8КБ-страниц. Страниц, которые PostgreSQL использует для организации всех данных — таблиц, индексов, последовательностей, TOAST-отношений.

Продолжить чтение "Заглянем в страницу PostgreSQL"

Пересказ статьи Robins Tharakan. Settling COUNT(*) vs COUNT(1) debate in Postgres 19

Недавнее изменение в основной ветке PostgreSQL принесло лучшее качество жизни очень общего паттерна SQL в плане оптимизации - улучшение производительности до 64% для SELECT COUNT(h), где h - столбец NOT NULL.

Если вы когда-либо задавались вопросом, что использовать - COUNT(*) или COUNT(1), или вы послушно придерживались использования COUNT(id) на не-NULL столбце, это изменение для вас.

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

Продолжить чтение "Разрешение спора между COUNT(*) и COUNT(1) в Postgres 19"

Пересказ статьи Darren Tan. SQL Best Practices: Hard-Learned Lessons from my years as a Software Engineer

База данных похожа на шутку: если ее приходится объяснять, значит, она, скорее всего, плохо спроектирована...

Представьте: 3 часа утра в субботу, а я сижу за столом, три часа на то, что должно быть простой обработкой пакета производственных данных. Задача казалась простой - обработать набор данных 1200 заказчиков. Что я не мог предвидеть, так это то, что на каждый вызов API должен срабатывать триггер с тысячами операций, происходящих в базе данных, превращая простую работу в ночной кошмар.

Эта бессонная ночь субботы дала мне больше в плане понимания оптимизации SQL, чем все курсы информатики, которые я когда-либо проходил. Хотя бизнес-команда в конце концов получила свои данные (хотя и с некоторым ожиданием), я получил нечто более ценное: глубокое уважение как к силе, так и подводным камням запросов SQL.

Являетесь ли вы начинающим разработчиком, только приступающим к работе, или опытным архитектором, я надеюсь, что, делясь усвоенными мной уроками, я помогу вам избежать некоторого негативного опыта, который я получил той ночью. Продолжить чтение "Лучшие практики SQL: уроки, усвоенные мной за годы работы инженером-программистом"

§ Komov S. M. усилил проверку задачи 192 (SELECT, обуч. этап).

§ Новая задача DML от selber опубликована под номером 19 (оценка сложности 3 балла). При этом выполнены следующие перестановки:

19 (старая) -> 13

13 -> (-7)

§ Популярные темы недели на форуме

Топик		Сообщений	Просмотров
 13 (DML)		4		6
 49 (Learn)		2		5
 10 (SELECT)		2		8
 47 (Learn)		2		7
 17 (DML)		2		5

Продолжить чтение "Новости за 2026-02-14 - 2026-02-20"

Автор: Dave Page, Lessons Learned Writing an MCP Server for PostgreSQL

За последние несколько месяцев мы разрабатывали pgEdge Postgres MCP Server — инструмент с открытым исходным кодом, который позволяет большим языковым моделям напрямую взаимодействовать с базами данных PostgreSQL через протокол Model Context Protocol. Он поддерживает Claude, GPT, локальные модели через Ollama и практически любой MCP-совместимый клиент, который можно к нему подключить. В процессе мы многое узнали о том, как обеспечить эффективную совместную работу ИИ и баз данных, и самый главный урок касался токенов.

Если вы хоть раз пользовались большой языковой моделью, вы знаете, что контекстные окна конечны, а токены стоят денег. Однако при работе с базой данных проблема обостряется до такой степени, к которой простое общение по электронной почте или написание прозы вас не готовят. Один единственный SELECT * в скромной таблице может вернуть десятки тысяч строк, каждая с дюжиной столбцов, и каждый символ этого вывода потребляет токены. Умножьте это на диалог, в котором LLM исследует схему, выполняет запросы и уточняет своё понимание, — и вы можете исчерпать контекстное окно до того, как будет сделано что-то действительно полезное.

Эта статья описывает стратегии, которые мы разработали для удержания расхода токенов под контролем, одновременно предоставляя LLM достаточно информации для продуктивной работы. Если вы создаёте свой MCP-сервер или просто интересуетесь практическими аспектами подключения LLM к структурированным данным, надеюсь, некоторые из этих уроков помогут вам избежать ошибок.

Продолжить чтение "Уроки, извлечённые при создании MCP-сервера для PostgreSQL"

Пересказ статьи DbVisualizer. Commenting in MySQL: Syntax, Versions, and Examples

Хорошие комментарии кода SQL помогают разработчикам понять, что делает запрос и почему он имеется - особенно, когда логика сложна и имеется множество соединений. MySQL предлагает несколько способов добавить контекст к вашему коду: однострочные комментарии, многострочные блоки и даже уникальные для MySQL комментарии с представлением версии и указаниями оптимизатору.

В этой статье обсуждается каждый стиль, показано, как их эффективно использовать и объясняются некоторые нюансы, связанные с комментариями версий и хинтами.
Продолжить чтение "Комментирование в MySQL: синтаксис, версии и примеры"

Автор: Ming Ying, How We Optimized Top K in Postgres

В базах данных под Top K понимают «верни мне K наилучших строк, упорядоченных по некоторому столбцу или значению». Обычно это означает «самые последние строки», «наивысшие оценки» или «наибольшие значения».

Казалось бы, это простая задача, которую Postgres должен решать без проблем. В конце концов, не можем ли мы просто создать индекс? Однако во многих рабочих инсталляциях Postgres Top K оказывается обманчиво сложной задачей. В этой статье рассматривается, где оптимизации Top K в Postgres показывают себя блестяще, где они дают сбой, и почему поисковые библиотеки вроде Lucene/Tantivy или базы данных, специализирующиеся на Top K, такие как ParadeDB, используют принципиально иной подход.

Продолжить чтение "Оптимизация Top K в PostgreSQL"