SQL-Ex blog

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

§ Автор добавил данные для проверки задачи 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"

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

§ Очередное усиление проверки задачи 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

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

Автор: Akhil Reddy Banappagari, Null and Empty String in Oracle vs SQL Server vs PostgreSQL

При планировании миграции баз данных в PostgreSQL именно мелочи часто становятся причиной самых серьёзных сбоев в рабочей среде. Одна из самых распространённых ловушек для разработчиков — это различная обработка значений NULL и пустых строк ('') в разных СУБД.

Хотя они могут казаться схожими концепциями, обозначающими отсутствие значения, то, как механизм базы данных их интерпретирует, может изменить результаты ваших запросов, нарушить уникальные ограничения или привести к сбоям загрузки данных. В этом руководстве мы сравним поведение Oracle, SQL Server и PostgreSQL, чтобы помочь вам избежать распространённых ошибок миграции.

Продолжить чтение "Значение NULL и пустая строка в Oracle, SQL Server и PostgreSQL"