SQL-Ex blog - Articles

"Простая" функция, которой нет: миграция функции T-SQL STR() в PostgreSQL

nospam@example.com (Sergey Moiseenko) — Sun, 19 Apr 2026 08:19:00 +0300

Пересказ статьи Assaf Fraenkel. The “Simple” Function That Isn’t: Migrating T-SQL’s STR() to PostgreSQL

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

Техническая спецификация

Стандартной спецификацией этой функции является:

STR ( float_expression [ , length [ , decimal ] ] )

Значение по умолчанию Length (длина): 10
Значение по умолчанию Decimal (масштаб): 0

Continue reading ""Простая" функция, которой нет: миграция функции T-SQL STR() в PostgreSQL"

Погружение в события ожиданий PostgreSQL

nospam@example.com (mssqlhelp) — Fri, 17 Apr 2026 12:06:00 +0300

Автор: Richard Yen, Understanding PostgreSQL Wait Events

Одним из самых полезных инструментов отладки в современном PostgreSQL является система событий ожиданий (wait events). Когда запрос замедляется или база данных становится ограниченной по процессору, естественно возникает вопрос: «Чего на самом деле ожидают сеансы?» Postgres предоставляет эту информацию через представление pg_stat_activity с помощью двух столбцов:

wait_event_type — тип события ожидания

wait_event — само событие ожидания

Эти поля показывают, на чём именно заблокирован фоновый процесс в данный момент. Среди различных типов ожидания одна категория часто вызывает путаницу:

LWLock

Если вы когда-либо видели панели мониторинга, полные ожиданий LWLock, вы не одиноки в своих сомнениях о том, что они означают и являются ли они проблемой.

Continue reading "Погружение в события ожиданий PostgreSQL"

Нулевая задержка autovacuum_vacuum_cost_delay - вас сметёт лавина записи

nospam@example.com (mssqlhelp) — Thu, 16 Apr 2026 17:35:00 +0300

Автор: Jeremy Schneider, Zero autovacuum_vacuum_cost_delay, Write Storms, and You

Несколько дней назад Шон Томас (Shaun Thomas) опубликовал статью в блоге pgEdge под названием «Контрольные точки, лавинная запись и вы». К сожалению, на многих корпоративных блогах больше нет возможности комментировать. Я оставил несколько комментариев в LinkedIn, но в целом позвольте мне сказать, что эта статья — отличное чтение, и я всегда рад, когда кто-то погружается в важную и обойдённую вниманием тему, даёт хорошее техническое описание и включает реальные результаты тестов для иллюстрации деталей.

У меня сегодня нет воспроизводимых реальных результатов тестов. Но у меня есть хорошая история и немного реальных данных.

Continue reading "Нулевая задержка autovacuum_vacuum_cost_delay - вас сметёт лавина записи"

EXPLAIN ANALYZE в PostgreSQL - практическое руководство для веб-разработчиков

nospam@example.com (Sergey Moiseenko) — Thu, 16 Apr 2026 09:26:00 +0300

Пересказ статьи Vishu Bommoju. EXPLAIN ANALYZE in PostgreSQL — A Practical Guide for Web Developers

Большинство медленных веб-приложений тормозят не из-за плохих фреймворков или плохих серверов.
Они виснут из-за медленных запросов к базам данных.

PostgreSQL дает нам одно оружие, которое важнее почти всего остального при отладке производительности:

EXPLAIN ANALYZE

В этой статье объясняется EXPLAIN ANALYZE с точки зрения его практического использования, а не как теория из учебника.

Continue reading "EXPLAIN ANALYZE в PostgreSQL - практическое руководство для веб-разработчиков"

Ошибки проектирования баз данных и как избежать и исправить их

nospam@example.com (Sergey Moiseenko) — Tue, 14 Apr 2026 11:22:00 +0300

Пересказ статьи Roxana Haidiner. Database Design Errors to Avoid & How To Fix Them

Даже сейчас, в 2025 году, при наличии мощных инструментов баз данных и облачных платформ разработчики все еще допускают элементарные ошибки при проектировании схемы. Они вызывают проблемы производительности, несогласованности данных и другие технологические проблемы.

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

Отсутствующие внешние ключи.

Отсутствующие или неверно спроектированные индексы.

Использование JSON и JSONB в реляционных базах данных.

Игнорирование нормализации (или её чрезмерное применение).

Нечеткие соглашения об именовании.

Отсутствие документации к схеме.

Continue reading "Ошибки проектирования баз данных и как избежать и исправить их"

Сравнение функций STUFF, REPLACE и WRITE в SQL Server

nospam@example.com (Sergey Moiseenko) — Sat, 01 Jul 2023 08:31:00 +0300

Пересказ статьи Aubrey Love. SQL STUFF vs SQL REPLACE vs SQL WRITE in SQL Server

Если вы когда-либо решали задачу со строками в Microsoft SQL Server, то, вероятно, уже знакомы с различными строковыми функциями, которые могут упростить процесс решения. Функции STUFF() и REPLACE() наиболее часто используются для обновления строковых значений в таблице. Но .WRITE() является относительно менее известной, не так ли? Continue reading "Сравнение функций STUFF, REPLACE и WRITE в SQL Server"

Обзор оконных функций PostgreSQL

nospam@example.com (Sergey Moiseenko) — Wed, 28 Jun 2023 08:38:00 +0300

Пересказ статьи rohind. An Overview of PostgreSQL Window Functions

Эта статья является руководством по использованию оконных функций SQL в приложениях, для которых требуется выполнять тяжелые вычислительные запросы. Данные множатся с поразительной скоростью. В 2022 в мире произведено и потреблено 94 зетабайтов данных. Сегодня у нас есть множество инструментов типа Hive и Spark для обработки Big Data. Несмотря на то, что эти инструменты различаются по типам проблем, для решения которых они спроектированы, они используют базовый SQL, что облегчает работу с большими данными. Оконные функции являются примером одной из таких концепций SQL. Это необходимо знать инженерам-программистам и специалистам по данным.
Continue reading "Обзор оконных функций PostgreSQL "

Контрольные точки, лавинная запись и вы

nospam@example.com (mssqlhelp) — Sat, 11 Apr 2026 18:48:00 +0300

Автор: Shaun Thomas,Checkpoints, Write Storms, and You

Каждая база данных должна примириться с двумя неприятными истинами: память быстра, но энергозависима, а диск медленен, но долговечен. Postgres справляется с этим противоречием с помощью журнала предзаписи (Write-Ahead Log, WAL), который регистрирует каждое изменение до того, как оно произойдёт. Но WAL не может расти бесконечно. В какой-то момент Postgres должен сбросить все накопившиеся грязные страницы на диск и объявить чистую начальную точку. Этот процесс называется контрольной точкой (checkpoint), и когда он идёт не по плану, пропускная способность может упасть до нуля.

Continue reading "Контрольные точки, лавинная запись и вы"

pg_column_size(): То, что вы видите, не всегда то, что получаете

nospam@example.com (mssqlhelp) — Fri, 10 Apr 2026 16:28:00 +0300

Автор: Lætitia AVROT, pg_column_size(): What you see is not what you get

Благодаря моему коллеге Озаиру (Ozair), который прислал мне запрос в JIRA: «Мне нужно удалить этот огромный столбец, каковы будут последствия?» Мой первый вопрос был: насколько он огромен? И тут кроличья нора открылась.

Это выглядит просто. Это просто. Просто используйте административную функцию pg_column_size(). Пока у вас нет атрибутов, обработанных TOAST. Тогда становится интересно.

Continue reading "pg_column_size(): То, что вы видите, не всегда то, что получаете"

Что такое collation (правило сортировки) и почему мои данные повреждены?

nospam@example.com (mssqlhelp) — Thu, 09 Apr 2026 17:30:00 +0300

Автор: Shaun Thomas, What is a Collation, and Why is My Data Corrupt?

Библиотека GNU C (glibc) версии 2.28 появилась на свет 1 августа 2018 года, и с тех пор Postgres уже не был прежним. Среди множества её изменений было масштабное обновление данных локалей для сопоставления (collation), приведшее их в соответствие с изданием 4 стандарта ISO 14651 (выпуск 2016 года) и Unicode 9.0.0. Это была не мелкая правка. Это была кульминация примерно 18 лет накопленных изменений в локалях, объединённых в одном выпуске.

Никто не устраивал вечеринку.

За этим последовал один из самых значительных и коварных инцидентов с целостностью данных в истории Postgres. Индексы молча становились повреждёнными, результаты запросов менялись без предупреждения, уникальным ограничениям больше нельзя было доверять. Самая страшная часть? Нужно было знать, что искать. Postgres не жаловался. Операционная система не жаловалась. Всё выглядело нормально, ровно до тех пор, пока это не переставало быть так.

Это история о том, как обновление библиотеки тихо повредило базы данных по всему миру, что сообщество Postgres сделало в ответ и как убедиться, что это никогда не повторится с вами.

Continue reading "Что такое collation (правило сортировки) и почему мои данные повреждены?"

Секционирование или шардинг в базах данных: в чем разница?

nospam@example.com (Sergey Moiseenko) — Thu, 09 Apr 2026 09:58:00 +0300

Пересказ статьи Sandeeppant. Partitioning vs. Sharding in Databases: What’s the Difference?

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

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

В этой статье мы узнаем:

Что такое секционирование и как это работает.

Что такое шардинг и чем оно отличается.

Практические примеры в MySQL и PostgreSQL.

Реальные случаи использования, которые освещают каждую технологию.

Continue reading "Секционирование или шардинг в базах данных: в чем разница?"

Внутреннее устройство WAL в PostgreSQL для инженеров данных

nospam@example.com (Sergey Moiseenko) — Tue, 07 Apr 2026 09:46:00 +0300

Пересказ статьи Jonathan Duran. PostgreSQL WAL Internals for Data Engineers

Понимание PostgreSQL WAL

Недавно, работая над проектом CDC, я осознал, что никогда в действительности не находил времени, чтобы вникнуть во внутреннее устройство PostgreSQL, которое делает возможным потоковую обработку транзакций. Все мы знаем CDC (захват измененных данных) как магию, которая позволяет нам помещать изменения данных почти в реальном времени в системы типа Kafka, Snowflake или data lake - но на самом деле основную работу выполняет специальный компонент инженерных решений PostgreSQL: журнал предупреждающей записи (WAL).

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

Нужно ли настраивать Vacuum в Postgres?

nospam@example.com (mssqlhelp) — Sun, 05 Apr 2026 13:28:00 +0300

Авторы: Elizabeth Garrett Christensen и Erik Jones, Do You Need to Tune Postgres Vacuum?

Если вы работаете с Postgres какое-то время, вы, вероятно, слышали, как кто-то упоминал «очистку» (vacuuming) базы данных или использовал термин «раздувание» (bloat). Оба эти понятия звучат как рутинная и надоедливая работа, но они — просто часть жизни здоровой базы данных. В современных версиях Postgres autovacuum обычно обрабатывает эти проблемы за кулисами. Но по мере роста вашей базы данных вы можете начать задаваться вопросом: достаточно ли настроек по умолчанию? Нужно ли мне запускать очистку Postgres вручную? Или почему моя база данных внезапно занимает гораздо больше места на диске, чем должна?

Давайте углубимся в то, зачем нужна очистка, как работает autovacuum и когда вам действительно нужно вмешаться и настроить его.

Continue reading "Нужно ли настраивать Vacuum в Postgres?"

Как быстро освоить CI/CD

nospam@example.com (mssqlhelp) — Fri, 03 Apr 2026 16:18:00 +0300

Автор: Itzik Gan Baruch, How to learn CI/CD fast

Непрерывная интеграция и непрерывная доставка (CI/CD) критически важны для ускорения выпуска программного обеспечения, и начать работать с ними не так сложно, как кажется. CI/CD стали краеугольной технической архитектурой успешных внедрений DevSecOps. CI/CD имеет репутацию сложной и труднодостижимой, но это не обязательно так. Современные инструменты позволяют командам начать работу с минимальной настройкой и управлением инфраструктурой. Вот как вы можете «быстро стартовать» с CI/CD и получить быстрые, наглядные победы в производительности для вашей команды DevSecOps.

Continue reading "Как быстро освоить CI/CD"

Обеспечение высокой доступности PostgreSQL с помощью Patroni и Ansible

nospam@example.com (mssqlhelp) — Thu, 02 Apr 2026 15:48:00 +0300

Автор: ByteGoblin/, Setting Up PostgreSQL High Availability with Patroni and Ansible

В современном мире, управляемом данными, обеспечение высокой доступности вашей базы данных имеет решающее значение для непрерывности бизнеса. PostgreSQL — мощная открытая реляционная база данных, которую можно настроить для обеспечения высокой доступности (High Availability, HA), чтобы минимизировать простои и сохранить доступ к данным. Одно из популярных решений для достижения высокой доступности PostgreSQL — использование Patroni (шаблона для управления кластерами PostgreSQL) в сочетании с Ansible (инструментом автоматизации, который упрощает развёртывание приложений, управление конфигурацией и оркестрацию).

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

Continue reading "Обеспечение высокой доступности PostgreSQL с помощью Patroni и Ansible"

CTE - Хороший, плохой, злой

nospam@example.com (mssqlhelp) — Tue, 31 Mar 2026 14:16:00 +0300

Автор: Radim Marek, Good CTE, bad CTE

Обобщённое табличное выражение (Common Table Expression, CTE) — это первая возможность, к которой часто обращаются разработчики, выходя за рамки базового SQL, а зачастую и единственная. Вы пишете подзапрос после WITH, даёте ему имя и используете в остальной части запроса. Он существует только на время выполнения этого запроса.

Но популярность CTE обычно связана не столько с модернизацией кода, сколько с обещанием императивной логики. Для многих CTE выступает в роли простого для понимания средства от «страшных запросов» и способа навязать базе данных порядок выполнения. Многие пишут запросы так, как будто они говорят оптимизатору: «сначала сделай это, затем сделай то».

Это создаёт проблему. CTE обеспечивают декомпозицию запросов, рекурсию и многосоставные DDL. Планировщик обрабатывает их по-разному в зависимости от того, как вы их пишете и используете. Долгое время (до PostgreSQL 12) CTE служили барьером для оптимизации. Планировщик не мог проталкивать условия предикатов внутрь них, не мог использовать индексы на нижележащих таблицах. Он не мог сделать ничего, кроме как материализовать их и просканировать полученный результат.

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

Continue reading "CTE - Хороший, плохой, злой"

Настройка производительности в PostgreSQL 17: Понимание параметров стоимости оптимизатора

nospam@example.com (Sergey Moiseenko) — Mon, 30 Mar 2026 10:12:00 +0300

Пересказ статьи Jeyaram Ayyalusamy. 32 - PostgreSQL 17 Performance Tuning: Understanding Optimizer Cost Parameters

PostgreSQL известна как одна из наиболее продвинутых реляционных баз данных с открытыми кодами, и одна из основных причин ее силы - оптимизатор запросов на основе стоимости.

Когда вы запускаете запрос, оптимизатор не выполняет его непосредственно. Он генерирует множество возможных планов выполнения и оценивает их стоимость. Выбирается план с самой низкой оценкой стоимости. Стоимость не измеряется в миллисекундах или циклах ЦП - она представляет собой абстрактные единицы, которые PostgreSQL использует для сравнения.

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

В этой статье мы:

Создадим таблицу с 10 миллионами строк для имитации реальной рабочей нагрузки.

Создадим индексы, чтобы дать возможность PostgreSQL построить несколько планов выполнения.

Подробно разберем модель стоимости в PostgreSQL.

Покажем, как настройка параметров стоимости может изменить решение при выборе плана.

Continue reading "Настройка производительности в PostgreSQL 17: Понимание параметров стоимости оптимизатора"

Cуперспособности EXPLAIN в PostgreSQL

nospam@example.com (mssqlhelp) — Fri, 27 Mar 2026 14:02:00 +0300

Автор: Richard Yen, EXPLAIN's Other Superpowers

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

EXPLAIN показывает выбранный планировщиком план выполнения, а EXPLAIN ANALYZE выполняет запрос и добавляет статистику времени выполнения. Для большинства задач настройки этого уже достаточно для получения большого объёма информации.

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

В этой статье мы рассмотрим некоторые из этих менее популярных опций.

Continue reading "Cуперспособности EXPLAIN в PostgreSQL"

Использование Patroni для создания кластера высокой доступности Postgres — Часть 3: HAProx

nospam@example.com (mssqlhelp) — Thu, 26 Mar 2026 13:49:00 +0300

Автор: Shaun Thomas, Using Patroni to Build a Highly Available Postgres Cluster—Part 3: HAProxy

Статьи серии:

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

Использование Patroni для создания кластера высокой доступности Postgres — Часть 1: etcd

Использование Patroni для создания кластера высокой доступности Postgres — Часть 2: Postgres и Patroni

Использование Patroni для создания кластера высокой доступности Postgres — Часть 3: HAProx

Добро пожаловать в третью часть нашей серии по созданию высокодоступного кластера Postgres с помощью Patroni! Часть первая была полностью посвящена созданию DCS с использованием etcd для обеспечения критически важного уровня DCS для кластера, а часть вторая добавила Patroni и Postgres в программный стек. Хотя на этом этапе можно остановиться и использовать кластер как есть, есть ещё один компонент, который сделает его гораздо более функциональным в целом.

Новым соединениям нужен способ легко и надёжно достигать основного узла. Patroni предоставляет REST-интерфейс для опроса каждого узла о его состоянии, что делает его идеальным решением для любого программного обеспечения или уровня балансировки нагрузки, совместимого с HTTP-проверками. Часть третья посвящена добавлению HAProxy для выполнения этой роли, завершая кластер уровнем маршрутизации.

Надеюсь, у вас всё ещё есть три виртуальные машины, на которых вы установили etcd, Postgres и Patroni. Они нам понадобятся для финального этапа, так что если вы ещё не прошли шаги из частей первой и второй, вернитесь, когда будете готовы.

В противном случае, давайте завершим кластер!

Continue reading "Использование Patroni для создания кластера высокой доступности Postgres — Часть 3: HAProx"

Использование Patroni для создания кластера высокой доступности Postgres — Часть 1: etcd

nospam@example.com (mssqlhelp) — Wed, 18 Mar 2026 13:00:00 +0300

Автор: Shaun Thomas, Using Patroni to Build a Highly Available Postgres Cluster—Part 1: etcd

Статьи серии:

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

Использование Patroni для создания кластера высокой доступности Postgres — Часть 1: etcd

Использование Patroni для создания кластера высокой доступности Postgres — Часть 2: Postgres и Patroni

Использование Patroni для создания кластера высокой доступности Postgres — Часть 3: HAProx

Предыдущая статья из цикла PG Phriday была посвящена архитектуре кластера Patroni — как и почему он устроен именно так. На этот раз речь пойдёт о непосредственном построении такого кластера. Я часто слышал, что эксплуатация Postgres может пугать, а Patroni находится на уровень выше. Что ж, со вторым я спорить не буду, но я могу хотя бы попытаться облегчить некоторые трудности.

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

Etcd

Postgres и Patroni

HAProxy

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

С этим разобрались, давайте приступим!

Continue reading "Использование Patroni для создания кластера высокой доступности Postgres — Часть 1: etcd"

Использование Patroni для создания кластера высокой доступности Postgres — Часть 2: Postgres и Patroni

nospam@example.com (mssqlhelp) — Mon, 23 Mar 2026 11:54:00 +0300

Автор: Shaun Thomas, Using Patroni to Build a Highly Available Postgres Cluster—Part 2: Postgres and Patroni

Статьи серии:

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

Использование Patroni для создания кластера высокой доступности Postgres — Часть 1: etcd

Использование Patroni для создания кластера высокой доступности Postgres — Часть 2: Postgres и Patroni

Использование Patroni для создания кластера высокой доступности Postgres — Часть 3: HAProx

Continue reading "Использование Patroni для создания кластера высокой доступности Postgres — Часть 2: Postgres и Patroni"

Полное руководство по обновлению PostgreSQL с 17 на 18

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

Автор: Ilya Kosmodemiansky, An Ultimate Guide to Upgrading Your PostgreSQL Installation: From 17 to 18

Обновления мажорных версий PostgreSQL — одна из тех задач, с которой регулярно приходится сталкиваться каждому администратору баз данных. Это рутинная операция, но она также полна мелких, потенциально опасных деталей, которые могут превратить простое окно обслуживания в инцидент. Выполнив сотни обновлений в разных средах за многие годы, я хочу поделиться комплексным, практическим руководством по обновлению с PostgreSQL 17 на 18, с особым вниманием к тому, что изменилось и что наконец-то улучшилось в самом процессе обновления.

Эта статья основана на моём докладе на PGConf.EU 2024, дополненном с учётом пути обновления 17→18 и значительных улучшений, появившихся в версии 18. В это время года мы обычно рекомендуем нашим клиентам обновляться: текущий релиз 18.3 достаточно стабилен.

Continue reading "Полное руководство по обновлению PostgreSQL с 17 на 18"

Вычисление скользящего среднего с помощью оконных функций в T-SQL

nospam@example.com (Sergey Moiseenko) — Wed, 25 Mar 2026 09:11:00 +0300

Пересказ статьи Jared Westover. Calculate a Moving Average with T-SQL Windowing Functions

Хотя мне нравится использовать SQL Server, есть несколько вещей, для которых лучше подходят другие инструменты. Например, вычисление скользящего среднего или накопительных итогов зачастую проще выполнить с помощью таких инструментов, как Power BI или Excel. Это связано с тем, что Microsoft разрабатывала эти программы, имея в виду подобную функциональность. Недавно мы оптимизировали сложный запрос скользящего среднего, написанный для SQL Server 2008R2. Сюрприз! В SQL Server нет встроенной функции для вычисления скользящего среднего. Но не беспокойтесь, я покажу вам, как это сделать.

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

Continue reading "Вычисление скользящего среднего с помощью оконных функций в T-SQL"

Представление о высокой доступности PostgreSQL как о слоях

nospam@example.com (mssqlhelp) — Sun, 22 Mar 2026 12:42:00 +0300

Автор: Umair Shahid, Thinking of PostgreSQL High Availability as Layers

Высокая доступность для PostgreSQL часто рассматривается как единое, большое, драматичное решение: «Делаем мы HA или нет?»

Такой подход толкает команды к двум крайностям:

«геройская архитектура», которая стоит дорого и всё равно вызывает напряжение при эксплуатации, или

минималистичная архитектура, которую все надеются, что будет просто продолжать работать.

Более спокойный способ проектирования — рассматривать HA и аварийное восстановление (DR) как слои. Вы начинаете с базового уровня, а затем добавляете конкретные возможности только тогда, когда ваши RPO/RTO и бюджет их оправдывают.

Давайте пройдём по слоям от «одного основного узла» до «многосайтовой готовности к аварийному восстановлению».

Continue reading "Представление о высокой доступности PostgreSQL как о слоях"

Подготовленные запросы (операторы) в PostgreSQL для начинающих

nospam@example.com (Sergey Moiseenko) — Sun, 22 Mar 2026 07:47:00 +0300

Пересказ статьи Tomasz Gintowt. PostgreSQL Prepared Queries (Statements) For Beginners

Когда мы пишем запросы SQL, то часто выполняем один и тот же запрос снова и снова лишь меняя значения.

PostgreSQL обладает функциональностью, которая помогает решить эту проблему, - подготовленные запросы (также называемые подготовленными операторами).

В этой статье мы выясним:

Что такое подготовленные запросы.

Чем они полезны.

Как их использовать в PostgreSQL.

Реальные примеры, которые вы сами сможете опробовать.

Никаких непонятных слов. Никакой сложной теории. Простые ясные примеры.
Continue reading "Подготовленные запросы (операторы) в PostgreSQL для начинающих"

Как PostgreSQL сканирует ваши данные

nospam@example.com (mssqlhelp) — Tue, 17 Mar 2026 18:19:00 +0300

Автор: Warda Bibi, How PostgreSQL Scans Your Data

Чтобы понять, как PostgreSQL сканирует данные, сначала нужно понять, как PostgreSQL их хранит.

Таблица хранится как набор 8-килобайтных страниц (по умолчанию) на диске. Каждая страница имеет заголовок, массив указателей на элементы (также называемых линейными указателями) и сами данные кортежей, растущие снизу вверх. Каждый кортеж имеет свой собственный заголовок, содержащий информацию о видимости: xmin, xmax, cmin/cmax и биты infomask.

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

Последовательное сканирование (Sequential Scan)

Индексное сканирование (Index Scan)

Сканирование только индекса (Index-Only Scan)

Сканирование по битовой карте (Bitmap Index Scan)

В этой статье мы рассмотрим каждый из этих типов сканирования по отдельности.

Continue reading "Как PostgreSQL сканирует ваши данные"

Настройка производительности в PostgreSQL 17: понимание преполагаемого и действительного планов выполнения

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

Пересказ статьи Jeyaram Ayyalusamy. 29 - PostgreSQL 17 Performance Tuning: Understanding Estimates vs. Actuals in Query Plans

Настройка производительности в PostgreSQL часто сводится к единственному навыку: умению читать планы выполнения. Команда PostgreSQL EXPLAIN ANALYZE - главный инструмент для этого. Она показывает не только то, как выполняется запрос, но и то, чего ожидал оптимизатор PostgreSQL, и что произошло на самом деле.

При просмотре плана выполнения вы всегда должны задать себе два больших вопроса:

Оправданы ли временные параметры, указанные в выводе команды EXPLAIN ANALYZE, для данного запроса?

В каком месте происходит внезапный скачок времени выполнения?

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

T-SQL в SQL Server 2025: нечеткий поиск строки II

nospam@example.com (Sergey Moiseenko) — Fri, 13 Mar 2026 08:40:00 +0300

Пересказ статьи Steve Jones. T-SQL in SQL Server 2025: Fuzzy String Search II

В последней статье мы проверяли нечеткое соответствие строк при помощи новых функций в SQL Server 2025. Мы знаем, что сравнение строк всегда вызывало сложности, когда у нас нет качественных данных. Если нам нужно точное совпадение, SQL Server работает отлично. Однако мы часто ждем от пользователей ввода значений без опечаток и знать, какие значения они хотят найти. Или хотя бы знать часть строки.

В SQL Server 2025 появилось несколько новых функций, которые помогают с нечетким совпадением строк. В последней статье были рассмотрены функции расстояния, EDIT_DISTANCE() и EDIT_DISTANCE_SIMILARITY(). В этой статье мы проверим две другие функции, JARO_WINKLER_DISTANCE() и JARO_WINKLER_SIMILARITY(). Как и другие функции, они находятся в предварительной версии (по состоянию на январь 2026 г.), так что будьте осторожны с использованием их в продакшене. Вам также необходимо включить эти функции как часть конфигурации области базы данных. Мы рассмотрели это в первой статье.

Это часть серии статей, посвященной тому, как язык T-SQL развивается в SQL Server 2025.

Примечание. Некоторые из этих изменений уже доступны в различных продуктах Azure SQL.
Continue reading "T-SQL в SQL Server 2025: нечеткий поиск строки II"

Общие проблемы в 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"

Статистика в 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"

Заглянем в страницу 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: уроки, усвоенные мной за годы работы инженером-программистом"

Комментирование в 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 - новая эра структурированного ввода?"

Где же мой кластерный индекс в 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"