Skip to content

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

Posted by Sergey Moiseenko on

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

Posted by Sergey Moiseenko on

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


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

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

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

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

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

Posted by mssqlhelp on

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