SQL-Ex blog

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

nospam@example.com (mssqlhelp) — Tue, 10 Mar 2026 11:49:00 +0300

Автор: 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 внезапно прекратился. Все сразу поняли, что в нём есть что-то, что кардинально отличает его от предшественников. Давайте поговорим о том, почему.

Continue reading "Как Patroni обеспечивает высокую доступность PostgreSQL"

Общие проблемы в SQL Server: Invalid Length

nospam@example.com (Sergey Moiseenko) — Mon, 09 Mar 2026 15:48:00 +0300

Пересказ статьи 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);

Continue reading "Общие проблемы в SQL Server: Invalid Length"

Новости за 2026-02-28 - 2026-03-06

nospam@example.com (Sergey Moiseenko) — Fri, 06 Mar 2026 23:27:00 +0300

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

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

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

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

Continue reading "Новости за 2026-02-28 - 2026-03-06"

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

nospam@example.com (mssqlhelp) — Wed, 04 Mar 2026 17:20:00 +0300

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

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

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

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

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

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

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

nospam@example.com (Sergey Moiseenko) — Wed, 04 Mar 2026 08:50:00 +0300

Пересказ статьи 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, зачем они нужны, как их можно использовать и о том, что позволяет отнести их к категории «специальных инструментов».

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

Теория множеств и пакетный режим в SQL Server

nospam@example.com (Sergey Moiseenko) — Sun, 01 Mar 2026 23:52:00 +0300

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

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

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

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

nospam@example.com (mssqlhelp) — Fri, 27 Feb 2026 19:39:00 +0300

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

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

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

Новости за 2026-02-21 - 2026-02-27

nospam@example.com (Sergey Moiseenko) — Fri, 27 Feb 2026 18:54:00 +0300

§ Очередная задача 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

Continue reading "Новости за 2026-02-21 - 2026-02-27"

Заглянем в страницу PostgreSQL

nospam@example.com (mssqlhelp) — Wed, 25 Feb 2026 12:44:00 +0300

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

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

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

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

Continue reading "Заглянем в страницу PostgreSQL"

Разрешение спора между COUNT(*) и COUNT(1) в Postgres 19

nospam@example.com (Sergey Moiseenko) — Wed, 25 Feb 2026 10:47:00 +0300

Пересказ статьи 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.

Continue reading "Разрешение спора между COUNT(*) и COUNT(1) в Postgres 19"

Лучшие практики SQL: уроки, усвоенные мной за годы работы инженером-программистом

nospam@example.com (Sergey Moiseenko) — Mon, 23 Feb 2026 10:53:00 +0300

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

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

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

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

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

Новости за 2026-02-14 - 2026-02-20

nospam@example.com (Sergey Moiseenko) — Fri, 20 Feb 2026 23:49:00 +0300

§ 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

Continue reading "Новости за 2026-02-14 - 2026-02-20"

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

nospam@example.com (mssqlhelp) — Fri, 20 Feb 2026 17:38:00 +0300

Автор: 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 к структурированным данным, надеюсь, некоторые из этих уроков помогут вам избежать ошибок.

Continue reading "Уроки, извлечённые при создании MCP-сервера для PostgreSQL"

Комментирование в MySQL: синтаксис, версии и примеры

nospam@example.com (Sergey Moiseenko) — Fri, 20 Feb 2026 09:03:00 +0300

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

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

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

Оптимизация Top K в PostgreSQL

nospam@example.com (mssqlhelp) — Wed, 18 Feb 2026 14:44:00 +0300

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

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

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

Continue reading "Оптимизация Top K в PostgreSQL"

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

nospam@example.com (mssqlhelp) — Tue, 17 Feb 2026 15:49:00 +0300

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

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

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

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

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

nospam@example.com (mssqlhelp) — Mon, 16 Feb 2026 18:08:00 +0300

Автор: 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 или создание таблиц из ничего"

JSON или TOON - новая эра структурированного ввода?

nospam@example.com (Sergey Moiseenko) — Sun, 15 Feb 2026 23:34:00 +0300

Пересказ статьи Marius Schröder. JSON vs TOON — A new era of structured input

Во времена, когда подсказки становятся все объемней, а модели искусственного интеллекта — все более мощными, встает один вопрос: как мы можем поддерживать низкими затраты и время обработки?

При программной работе с LLM структурированный вывод стал уже стандартным подходом. Вы можете попросить ИИ ответить в определенном формате, например, JSON. Определяя схему модели и идеально описывая, что означает каждое поле, ИИ пытается понять контекст и наполнить вывод "знанием, которое он считает лучшим и доверительным" (или насколько близко к этому подходит LLM).

Становится проще, чем когда-либо, работать с результатами ИИ. Но как насчет ввода?

Хотя мы можем сделать вывод аккуратным и структурированным, большинство из нас все еще выгружает огромный JSON, YAML или даже набор данных в виде плоского текста в подсказки. Это не только долго и дорого, но также далеко не эффективно с точки зрения токенов.

Поэтому было только делом времени появление нового формата, который бы исправил ситуацию.

И тут появился TOON. Continue reading "JSON или TOON - новая эра структурированного ввода?"

Новости за 2026-02-07 - 2026-02-13

nospam@example.com (Sergey Moiseenko) — Fri, 13 Feb 2026 23:20:00 +0300

§ Автор добавил данные для проверки задачи 55 (DML).

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

Топик		Сообщений	Просмотров
 20 (DML)		5		9
 12 (DML)		4		7
 Guest's book		2		9

§ Авторы недели на форуме

Автор		Сообщений
 selber  	4
 rock_4  	3
 s108	2

Continue reading "Новости за 2026-02-07 - 2026-02-13"

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

nospam@example.com (mssqlhelp) — Thu, 12 Feb 2026 15:10:00 +0300

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

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

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

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

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

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

nospam@example.com (mssqlhelp) — Fri, 13 Feb 2026 11:47:00 +0300

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

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

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

T-SQL в SQL Server 2025: конкатенация строк

nospam@example.com (Sergey Moiseenko) — Fri, 13 Feb 2026 10:06:00 +0300

Пересказ статьи Steve Jones. T-SQL in SQL Server 2025: Concatenating Strings

Как и многие из вас, я часто соединяю строки (конкатенирую) при помощи простого арифметического оператора +. У нас есть еще и другие способы соединения строк, но в SQL Server 2025 появился еще один новый оператор. Это оператор двойной трубы (||). В этой статье мы разберемся, как он работает, и сравним с другими вариантами.

Новый оператор

Он действительно документирован, хотя и после || в MS Learn. Идея состоит в том, что соединяться будут: Continue reading "T-SQL в SQL Server 2025: конкатенация строк"

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

nospam@example.com (mssqlhelp) — Tue, 10 Feb 2026 19:02:00 +0300

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

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

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

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

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

nospam@example.com (mssqlhelp) — Wed, 11 Feb 2026 12:44:00 +0300

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

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

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

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

Эффективные стратегии для хранения и парсинга JSON в SQL Server

nospam@example.com (Sergey Moiseenko) — Sun, 08 Feb 2026 23:37:00 +0300

Пересказ статьи Edward Pollack. Effective Strategies for Storing and Parsing JSON in SQL Server

Подобно XML, JSON является открытым стандартным форматом хранения данных, метаданных, параметров или других неструктурированных или полуструктурированных данных. Из-за его активного использования в современных приложениях он обречен попасть в базы данных, где его необходимо будет хранить, сжимать, изменять, выполнять поиск и извлекать.

Несмотря на то, что реляционные базы данных не являются идеальным местом для хранения и управления мало структурированными данными, требования, предъявляемые приложениями, могут зачастую преодолевать "оптимальный" проект базы данных. Это удобно иметь данные JSON рядом со связанными с ними реляционными данными и эффективная организация хранилища с самого начала может сэкономить значительное время и ресурсы в будущем.

Эта статья посвящена тому, как хранится JSON в SQL Server и разным способам, с помощью которых он записывается, читается и обслуживается. Continue reading "Эффективные стратегии для хранения и парсинга JSON в SQL Server"

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

nospam@example.com (mssqlhelp) — Sun, 25 Jan 2026 11:52:00 +0300

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

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

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

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

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

nospam@example.com (mssqlhelp) — Tue, 27 Jan 2026 13:20:00 +0300

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

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

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

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

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

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

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

nospam@example.com (mssqlhelp) — Fri, 06 Feb 2026 18:36:00 +0300

Автор: 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"

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

nospam@example.com (mssqlhelp) — Fri, 30 Jan 2026 16:11:00 +0300

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

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

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

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

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

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

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

nospam@example.com (mssqlhelp) — Sun, 01 Feb 2026 12:28:00 +0300

Автор: 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 раз"

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

nospam@example.com (mssqlhelp) — Tue, 03 Feb 2026 14:10:00 +0300

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

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

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

shared_buffers

work_mem

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

Новости за 2026-01-31 - 2026-02-06

nospam@example.com (Sergey Moiseenko) — Fri, 06 Feb 2026 18:42:00 +0300

§ Очередное усиление проверки задачи 20 (DML) данными от saphirion.

Автор добавил данные для проверки задачи 42 (DML).

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

Топик		Сообщений	Просмотров
 308 (SELECT)		10		3
 20 (DML)		3		6
 42 (DML)		3		2
 43 (Learn)		2		8
 21 (DML)		2		3

Continue reading "Новости за 2026-01-31 - 2026-02-06"

Как обнаружить и устранить конфликты на уровне строк в PostgreSQL с помощью pgrowlocks

nospam@example.com (Sergey Moiseenko) — Thu, 05 Feb 2026 09:06:00 +0300

Пересказ статьи Matheus dos Santos. How to Detect and Fix Row-Level Contention in PostgreSQL Using pgrowlocks

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

В этом руководстве мы представим практический подход к использованию pgrowlocks. Мы начнем с установки расширения с последующей имитацией блокировки, чтобы увидеть ее в действии и, наконец, построим мощную глобальную функцию для идентификации блокировок уровня строки по всей базе данных с данными о пользователе, запросе и продолжительности.
Continue reading "Как обнаружить и устранить конфликты на уровне строк в PostgreSQL с помощью pgrowlocks"

Понимание combinebackup в PostgreSQL

nospam@example.com (Sergey Moiseenko) — Tue, 03 Feb 2026 11:24:00 +0300

Пересказ статьи Tomasz Gintowt. Understanding pg_combinebackup in PostgreSQL

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

В этой статье мы разберем, что делает pg_combinebackup, как он работает и как вы можете использовать его в ваших стратегиях резервирования и восстановления.
Continue reading "Понимание combinebackup в PostgreSQL"

Проблема неявных транзакций

nospam@example.com (Sergey Moiseenko) — Sun, 01 Feb 2026 11:16:00 +0300

Пересказ статьи Steve Jones. The Challenge of Implicit Transactions

Сценарий

Вы выполняете такой код:

Все выглядит хорошо. Я выполнил вставку и вижу данные в таблице. Я тороплюсь, поэтому щелкаю "close" (закрыть) на вкладке и вижу это:

Я настолько привык к этим раздражающим меня сообщениям в SSMS, что я нажимаю «Нет», чтобы избавиться от них и закрыть окно.
Continue reading "Проблема неявных транзакций"

Новости за 2026-01-24 - 2026-01-30

nospam@example.com (Sergey Moiseenko) — Fri, 30 Jan 2026 18:43:00 +0300

§ Автор уточнил формулировку и усилил проверку задачи 308 (SELECT, рейтинг).

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

Топик		Сообщений	Просмотров
 Certification		3		12
 3 (SELECT)		3		10
 58 (DML)		2		3
 20 (DML)		2		5
 191 (SELECT)		2		4

Continue reading "Новости за 2026-01-24 - 2026-01-30"

Подводные камни Truncate Table

nospam@example.com (Sergey Moiseenko) — Tue, 27 Jan 2026 09:41:00 +0300

Пересказ статьи Peter Skoglund. Truncate Table Pitfalls

Усечение таблицы может быть замечательно быстрым - и чрезвычайно опасным при неосмотрительном использовании. Если вы хотите иметь скорость и не разочароваться, тут дается практическое, готовое для интервью руководство по реальным подводным камням TRUNCATE TABLE в SQL Server и то, как избежать их.

Справка

TRUNCATE TABLE является операцией DDL, которая освобождает страницы (эффективно журнализированные) и сбрасывает IDENTITY к начальному значению. При этом триггеры DELETE не срабатывают. Возможен откат при выполнении внутри транзакции.

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

Начиная с SQL Server 2016, вы можете усекать конкретные секции: TRUNCATE TABLE dbo.Fact WITH (PARTITIONS (4 TO 6)); (индексы должны быть выровнены).

Continue reading "Подводные камни Truncate Table"

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

nospam@example.com (mssqlhelp) — Sat, 24 Jan 2026 18:28:00 +0300

Автор: 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"

Новости за 2026-01-17 - 2026-01-23

nospam@example.com (Sergey Moiseenko) — Fri, 23 Jan 2026 19:23:00 +0300

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

Топик		Сообщений	Просмотров
 192 (Learn)		12		8
 1 (SELECT)		7		9
 39 (Learn)		4		9
 10 (DML)		3		6
 25 (Learn)		2		9

§ Авторы недели на форуме

Автор		Сообщений
 pegoopik  	12
 selber  	8
 Meilleur_NG  	3
 rock_4  	2
 KhNadezhda	2

Continue reading "Новости за 2026-01-17 - 2026-01-23"

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

nospam@example.com (mssqlhelp) — Thu, 22 Jan 2026 21:08:00 +0300

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

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

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

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

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

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

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

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

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

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

nospam@example.com (mssqlhelp) — Wed, 21 Jan 2026 11:40:00 +0300

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

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

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

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

Индексы BRIN в PostgreSQL для специалистов в SQL Server

nospam@example.com (mssqlhelp) — Tue, 20 Jan 2026 11:44:00 +0300

Автор: Klaus Aschenbrenner, BRIN Indexes in PostgreSQL

Когда специалисты по SQL Server начинают серьёзно работать с PostgreSQL, большая часть обучения кажется комфортной. Таблицы ведут себя ожидаемо, транзакции знакомы, а B-деревья выглядят обнадёживающе похожими на то, что вы использовали годами в SQL Server. Затем вы сталкиваетесь с индексами BRIN.

На первый взгляд они кажутся почти безрассудными: нет указателей на строки, нет точной навигации и явное принятие ложных срабатываний. И всё же на очень больших таблицах индексы BRIN часто обеспечивают прирост производительности, для достижения которого в SQL Server потребовались бы кластерные индексы, секционирование или даже columnstore-индексы. Чтобы понять почему, нужно посмотреть не только на то, что делает BRIN, но и на то, как он работает внутри.

Continue reading "Индексы BRIN в PostgreSQL для специалистов в SQL Server"

Утраченный символ - от EBCDIC до Emoji

nospam@example.com (mssqlhelp) — Mon, 19 Jan 2026 13:47:00 +0300

Автор: Joe Celko, Getting Out of Character

Молодые программисты выросли с ASCII и Unicode как единственными способами представления символьных данных в компьютере. Но в тёмные века, до того как мы изобрели грязь и вошли в каменный век, были и другие претенденты.

Continue reading "Утраченный символ - от EBCDIC до Emoji"

Массовая вставка T‑SQL или OPENROWSET: импорт CSV, проблемы доступа к файлам и скрипт PowerShell

nospam@example.com (Sergey Moiseenko) — Sun, 18 Jan 2026 16:43:00 +0300

Пересказ статьи Rick Dobson. T‑SQL BULK INSERT vs OPENROWSET: CSV Imports, File Access Gotchas, and A PowerShell Script

Большинство руководств по массовой вставке SQL и SQL Server openrowset игнорируют проблемы доступа к файлам, которые могут прервать импорт. И оператор bulk insert, и функция openrowset выполняются под аккаунтом службы SQL Server при чтении файла источника. Аккаунт службы SQL Server должен иметь разрешение на чтение файла или папки, где файл находится. Также удобно иметь разрешения на чтение и выполнение, а также вывод содержимого папки. Кроме того, нестандартные места размещения файла источника (например, C:\Users\Public\Downloads) могут не предоставлять доступ на чтение по умолчанию аккаунту службы SQL Server - всегда проверяйте это перед использованием.

Импорт данных из файла источника в таблицу SQL Server является обычной операцией, но она озадачивает многих новичков и порой вызывает трудности даже у опытных разработчиков в сложных сценариях. В этой статье изучается импорт файлов CSV в таблицы SQL Server либо с помощью оператора BULK INSERT, либо функции openrowset в операторе SELECT. Continue reading "Массовая вставка T‑SQL или OPENROWSET: импорт CSV, проблемы доступа к файлам и скрипт PowerShell"

Новости за 2026-01-10 - 2026-01-16

nospam@example.com (Sergey Moiseenko) — Fri, 16 Jan 2026 19:31:00 +0300

§ Новая задача от нового автора (Komov S. M.) выставлена на обучающий этап под номером 192 (сложность 2 балла).

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

Топик		Сообщений	Просмотров
 43 (SELECT)		6		8
 58 (DML)		4		5
 17 (Learn)		3		8
 53 (DML)		2		3
 36 (Learn)		2		9

Continue reading "Новости за 2026-01-10 - 2026-01-16"

Надежность PostgreSQL: как WAL помогает восстановить данные

nospam@example.com (Sergey Moiseenko) — Wed, 14 Jan 2026 12:43:00 +0300

Пересказ статьи Duc Ngo. PostgreSQL Durability: How WAL Helps You Recover Data

С целью повышения производительности PostgreSQL сначала сохраняет изменения в RAM.

RAM ненадежна, поэтому сбой питания может привести к потере данных.

Write-Ahead Logging (WAL - упреждающая журнализация) записывает изменения перед записью на диск

WAL гарантирует согласованность и надежность.

После краха системы, PostgreSQL может восстановить утерянные изменения, используя WAL.

Continue reading "Надежность PostgreSQL: как WAL помогает восстановить данные"

Повышение производительности PostgreSQL: пошаговое руководство по использованию pg_hint_plan

nospam@example.com (Sergey Moiseenko) — Mon, 12 Jan 2026 11:04:00 +0300

Пересказ статьи Matheus dos Santos. Mastering PostgreSQL Performance: A Step-by-Step Guide to pg_hint_plan

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

Это руководство проведет вас через весь процесс, начиная с установки pg_hint_plan из источника до использования его, чтобы принудительно выполнить сканирование индекса на большом наборе данных, демонстрируя возможности непосредственного управления производительностью вашего запроса.
Continue reading "Повышение производительности PostgreSQL: пошаговое руководство по использованию pg_hint_plan"

Основы GROUP BY в SQL

nospam@example.com (mssqlhelp) — Sat, 10 Jan 2026 19:41:00 +0300

Joe Celko, SQL GROUP BY Basics

Предложения GROUP BY и HAVING в SQL существуют с самого начала языка, в своей простейшей форме. Изначальная идея заключалась в том, что вы создаёте рабочую таблицу с помощью предложений SELECT ... FROM ... WHERE, а затем разбиваете этот результирующий набор на группы. Группа определяется как набор строк с одинаковыми значениями для столбцов группировки. Негруппируемые столбцы должны были быть свойствами группы (обычно агрегатными функциями), формулами или вычислениями, выполненными на них, либо константами (что технически также является свойством группы).

Затем каждая группа сводится к одной строке. Важное понятие здесь — исходная таблица больше не существует. Однако если вы достаточно взрослый, чтобы работать с самыми ранними версиями SQL Server, синтаксис Sybase не избавлялся от исходной таблицы. Это приводило к некоторым проблемам. Он предоставлял доступ к исходным данным строк вместе с агрегированными данными.

Исходное предложение HAVING затем применялось к каждой из строк в новой сгруппированной таблице. Это означало, что оно выполнялось после предложения WHERE, которое строило исходную таблицу.

Позже мы добавили оконные функции, расширения для GROUP BY в форме ROLLUP, CUBE и GROUPING SETS. Но с исходными простыми конструкциями GROUP BY – HAVING всё ещё можно сделать довольно много. Их преимущество в том, что они выполняют свою работу за один просмотр таблицы, в то время как более новые конструкции могут требовать временного хранения или нескольких проходов по данным. Исходные версии переносимы и предсказуемы. Спустя все эти десятилетия они теперь хорошо оптимизированы.

Continue reading "Основы GROUP BY в SQL"

Новости за 2026-01-03 - 2026-01-09

nospam@example.com (Sergey Moiseenko) — Sat, 10 Jan 2026 16:33:00 +0300

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

Топик		Сообщений	Просмотров
 40 (SELECT)		6		8
 149 (SELECT)		5		4
 189 (SELECT)		3		3

§ Авторы недели на форуме

Автор		Сообщений
 pegoopik  	5
 selber  	5
 gennadi_s  	2
 Paulus73	2

Continue reading "Новости за 2026-01-03 - 2026-01-09"

Объяснение PostgreSQL REGEXP_MATCH: синтаксис, примеры использования и подводные камни

nospam@example.com (Sergey Moiseenko) — Wed, 07 Jan 2026 23:28:00 +0300

Пересказ статьи DbVisualizer. PostgreSQL REGEXP_MATCH Explained: Syntax, Use Cases, Pitfalls

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

Если вам когда-либо требовалось извлечь номер телефона из текста, проверить адрес электронной почты или захватить поименованный фрагмент строки, REGEXP_MATCH поможет вам сделать это за один шаг SQL.

Ниже приведен практический экскурс в специфику этой функции: синтаксис, возвращаемые значения, общие случаи использования и некоторые ошибки, которых следует избегать в продакшене. Continue reading "Объяснение PostgreSQL REGEXP_MATCH: синтаксис, примеры использования и подводные камни"