Skip to content

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

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


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

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

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

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


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

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

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

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


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

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

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

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


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



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



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

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

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

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


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

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

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

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

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

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


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

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

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

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

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

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


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

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

13 -> (-7)


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

Топик		Сообщений	Просмотров
13 (DML) 4 6
49 (Learn) 2 5
10 (SELECT) 2 8
47 (Learn) 2 7
17 (DML) 2 5
Продолжить чтение "Новости за 2026-02-14 - 2026-02-20"

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

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


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


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


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

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

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

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


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

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

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

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


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


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

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

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

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


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



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

Продолжить чтение "Кэш страниц Linux и PostgreSQL"

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

Автор: 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, помещающие по одной записи за раз в файл. Начните думать о работе с целыми множествами.

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

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

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


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

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

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

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

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

И тут появился TOON. Продолжить чтение "JSON или TOON - новая эра структурированного ввода?"

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

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


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

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

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

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

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

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

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


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


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