🔍 Что такое планировщик запросов и как он работает в PostgreSQL.

Когда вы отправляете в базу простой запрос вроде:

SELECT * FROM users WHERE age > 30 ORDER BY age;

кажется, что PostgreSQL просто «читает таблицу и возвращает данные».
Но на самом деле перед выполнением запроса включается мощный мозг — планировщик запросов.

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

🧠 Что такое планировщик запросов?

Планировщик запросов — это компонент СУБД, который анализирует SQL-запрос и выбирает оптимальный план его выполнения.

Это как навигатор: вы указываете точку назначения, а он выбирает маршрут — короткий, быстрый или сбалансированный.

В PostgreSQL планировщик — часть системы optimizer (оптимизатора), и это один из самых серьёзных элементов движка.

⚙️ Как работает планировщик?

Когда вы отправляете запрос, PostgreSQL проходит несколько стадий:

1️⃣ Парсинг (разбор запроса)

Проверка синтаксиса, построение дерева запроса.

2️⃣ Анализ статистики

Планировщик смотрит в специальные системные таблицы и оценивает:

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

Это позволяет понять: выборка будет маленькой или огромной?

3️⃣ Генерация возможных планов

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

- полное сканирование таблицы (Seq Scan);
- использование индекса (Index Scan);
- частичное чтение индекса (Index Only Scan);
- Bitmap Index Scan;
- разные виды JOIN: Nested Loop, Hash Join, Merge Join;
- выполнение фильтра до или после соединения;
- сортировки, группировки и т. д.

4️⃣ Оценка стоимости каждого плана

Каждому варианту присваивается стоимость из учета затрачиваемых на выполнения запроса ресурсов (cost):
чем меньше cost — тем быстрее выполнение.

Учитывается:

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

5️⃣ Выбор оптимального плана

Планировщик выбирает план с наименьшей стоимостью — и передаёт его исполнительному модулю (executor).

🔎 Пример: почему запрос иногда «не использует индекс»

Многие удивляются:

«Я создал индекс, но PostgreSQL игнорирует его!»

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

Например, если таблица маленькая или условие слишком широкое, индекс не уменьшит объём работы, а вероятно даже увеличит.

Планировщик часто прав — он работает на основании статистики.

Знаете ли вы, что в PostgreSQL можно создавать свои собственные программки прямо внутри СУБД?

В PostgreSQL есть много встроенных функций, задача которых облегчать нам жизнь.

Например:

- round(3.14159, 2) возвращает 3.14
- length('PostgreSQL') возвращает 10
- now() возвращает текущую дату и время

Почти любая операция уже готова к использованию.

А что, если вам нужно каждый день считать некоторый финансовый показатель магазина, например — цена × количество × (1 - скидка) × (1 + НДС) с округлением, то писать это заново утомительно, а готового решения вероятно не будет.

Создайте свою программу, то есть функцию прямо на SQL:

CREATE OR REPLACE FUNCTION calc_revenue(price NUMERIC, qty INTEGER, discount NUMERIC DEFAULT 0)
RETURNS NUMERIC AS
$$
SELECT round(price * qty * (1 - discount) * 1.20, 2);
$$ LANGUAGE SQL;

Теперь просто вызываете функцию, указывая там свои параметры:

SELECT calc_revenue(1000, 5, 0.1); — 5400.00

Код чище, ошибок меньше, удобно переиспользовать.

📊 Данные как зеркало бизнеса: что они говорят о компании ?

У каждого бизнеса есть своё зеркало.
Нет, не то, в котором отражается офис или логотип.
А то, в котором отражается его настоящее состояние — сильные стороны, слабые места, ошибки, победы и возможности.
И этим зеркалом являются данные.

🔍 1. Данные показывают не то, что бизнес хочет видеть, а то, что есть на самом деле.

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

В цифрах нет эмоций.
Нет оправданий.
Нет «нам казалось».

Есть только факты.
И это делает данные самым честным источником истины в компании.

🧭 2. Данные показывают направление развития.

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

Данные — это навигатор.
Без него можно долго ехать красиво, но в неверную сторону.

🫥 3. Данные подсвечивают проблемы, которые иначе останутся в тени.

Часто компания узнаёт о проблеме только тогда, когда она становится слишком большой.

Но данные умеют предупреждать заранее:

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

Если смотреть в зеркало регулярно — можно заметить трещины, пока они ещё маленькие.

📈 4. Данные показывают зрелость компании

У зрелых компаний есть культура измерений.
Они знают свои ключевые метрики, отслеживают изменения, строят прогнозы и принимают решения осознанно.

У незрелых — хаос.
Данные либо отсутствуют, либо не доверяют тем, что есть, либо смотрят на них только тогда, когда «припекло».

Зрелость бизнеса начинается там, где начинается зрелость работы с данными.

💬 5. Что главное?

Данные — это не просто отчёты.
Это не цифры ради цифр.
Это голос бизнеса.

Если прислушаться, данные говорят:

- где вы сильны,
- где ошибаетесь,
- куда стоит идти,
- а куда — точно не стоит.

И задача аналитиков — не просто собрать эти данные, а помочь компании услышать себя.

🏁 Итог

Данные — это отражение бизнеса.
Аналитика — способ увидеть это отражение ясно.
И те, кто умеют с этим работать, дают компании шанс расти осознанно, а не вслепую.

Всем привет.
Разберем прошлый вопрос про псевдонимы.
Правильным ответом был: В GROUP BY и ORDER BY.
Это вот такая особенность PostgreSQL.
В некоторых других СУБД псевдоним не работает даже в GROUP BY.
Что кажется логичным с точки зрения логического порядка работы операторов внутри системы.
В HAVING и WHERE псевдоним точно не работает, т.к. сам SELECT работает позже чем эти два.

🧠 SQL-запрос, который должен знать каждый аналитик: накопительный итог в PostgreSQL.

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

❌ Многие начинают с подзапросов и GROUP BY
✅ Но в PostgreSQL это решается одной оконной функцией

Разберём на примере.

Допустим, есть таблица orders:

order_date    | amount
--------------+--------
2024-01-01    | 100
2024-01-02    | 200
2024-01-03    | 150

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

🔥 Правильный SQL-запрос:

SELECT
      order_date,
      amount,
      SUM(amount) OVER (ORDER BY order_date) AS running
FROM orders
ORDER BY order_date;

📌 Что здесь происходит

- SUM(amount) — считаем сумму
- OVER() — превращает агрегат в оконную функцию
- ORDER BY order_date — задаёт порядок накопления

👉 PostgreSQL сам «идёт» по строкам и суммирует значения.

Результат будет таким:

order_date  | amount| running
------------+-------+--------
2024-01-01  |   100 |  100               
2024-01-02  |   200 |  300   
2024-01-03  |   150 |  450   

💡 Почему это важно:

- без подзапросов
- читаемый SQL
- часто спрашивают на собеседованиях по SQL

Если ты изучаешь SQL, PostgreSQL и аналитику данных, оконные функции — обязательный пункт.

🕒 7 полезных функций для работы с датами и временем в PostgreSQL.

Если ты работаешь с SQL, то рано или поздно упрёшься в даты.
Фильтры, группировки, периоды, интервалы — всё это про них.

Разберём 7 функций PostgreSQL, которые реально нужны в работе.

1️⃣ NOW() — текущее дата и время:

SELECT NOW(); — 2025-12-16 14:23:10.456

Используется, когда нужно «текущее состояние» — сейчас, в этот момент.

2️⃣ CURRENT_DATE — текущая дата (без времени):

SELECT CURRENT_DATE; — 2025-12-16

Удобно для фильтрации по дням.

3️⃣ DATE_TRUNC() — усечение даты:

SELECT DATE_TRUNC('month', '2025-12-16'); — 2025-12-01 00:00:00

Очень часто используется для:

- группировки по месяцам
- неделям
- дням

4️⃣ AGE() — разница между датами:

SELECT AGE('2025-12-16', '2025-11-10'); — 1 mon 6 days

Возвращает разницу в удобном формате, а не просто число дней.

5️⃣ EXTRACT() — получить часть даты:

SELECT EXTRACT(YEAR FROM '2025-12-16');— 2025

Можно извлекать: YEAR, MONTH, DAY, HOUR, WEEK и т.д.

6️⃣ INTERVAL — работа с периодами времени

SELECT '2025-12-16'::date + INTERVAL '7 days'; — 2025-12-23

Незаменимо для:

- расчёта дедлайнов
- временных окон
- анализа периодов

7️⃣ TO_CHAR() — форматирование даты:

SELECT TO_CHAR('2025-12-16', 'YYYY-MM'); — 2025-12

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

🐘 Чем на самом деле занимаются администраторы баз данных (DBA).

Про DBA часто думают так:

«Ну… это человек, который следит, чтобы база не упала».

И да — это правда.
Но это лишь процентов 10 от того, чем DBA занимается на самом деле.

Разберёмся 👇

🔧 1. DBA отвечают за надёжность данных

Для бизнеса данные — это деньги, клиенты и история.
DBA делают всё, чтобы:

- данные не пропали
- данные не повредились
- данные можно было восстановить

Бэкапы, репликации, тесты восстановления — их ежедневная рутина.

⚡️ 2. DBA борются за производительность

Если запросы вдруг стали «тормозить»,
скорее всего, DBA уже это заметил.

Они:

- анализируют планы выполнения
- ищут узкие места
- настраивают индексы
- оптимизируют конфигурацию БД

И делают так, чтобы система выдерживала рост нагрузки.

🔐 3. DBA отвечают за безопасность

Кто имеет доступ к данным?
Кто может читать, кто — изменять, а кто — только смотреть?

DBA настраивают:

- роли и права
- доступы
- защиту от случайных и неслучайных ошибок

Чтобы данные не «утекали» и не ломались.

🚑 4. DBA — первые, кого будят ночью

Если база «легла» в 3 часа ночи —
DBA узнаёт об этом первым.

Он:

- ищет причину
- поднимает систему
- минимизирует потери
- делает выводы, чтобы это не повторилось

Спокойствие продакшена — их заслуга.

🧠 5. DBA — это про системное мышление

Хороший DBA понимает не только базу данных, но и:

- как работает приложение
- как идут запросы
- как растёт нагрузка
- где может возникнуть проблема

Они думают на несколько шагов вперёд.

🏁 Итог

DBA — это не просто «админ базы».
Это инженер, который делает так, чтобы бизнес мог спокойно работать, масштабироваться и не бояться за свои данные.

Если база работает стабильно и быстро —
скорее всего, где-то рядом есть хороший DBA.

UNION, EXCEPT, INTERSECT — операции объединения множеств в SQL.

В SQL есть мощный инструмент, про который знают не все,
но который сильно упрощает запросы — операции над множествами.

Если коротко:
они позволяют объединять и сравнивать результаты запросов.

Разберёмся 👇
------------------------------------------------------------------
🔹 UNION — объединить результаты

UNION объединяет результаты двух запросов и убирает дубликаты.

SELECT user_id FROM users_2024
UNION
SELECT user_id FROM users_2025;

Получим всех уникальных пользователей за два года.

Если дубликаты нужны — используйте UNION ALL.

------------------------------------------------------------------
🔹 INTERSECT — найти общее

INTERSECT возвращает только те строки,
которые есть в обоих результатах.

SELECT user_id FROM paid_users
INTERSECT
SELECT user_id FROM active_users;

Пользователи, которые и платят, и активны.


------------------------------------------------------------------
🔹 EXCEPT — найти разницу

EXCEPT показывает строки,
которые есть в первом запросе, но отсутствуют во втором.

SELECT user_id FROM users
EXCEPT
SELECT user_id FROM banned_users;

Все пользователи, кроме заблокированных.

------------------------------------------------------------------
⚠️ Важно помнить

Чтобы операции работали корректно, необходимо:

- одинаковое количество колонок
- одинаковые типы данных
- одинаковый порядок колонок

И да — порядок запросов в EXCEPT имеет значение.

Когда это реально полезно:

- сравнение сегментов
- анализ изменений
- поиск пересечений аудиторий
- очистка данных
- сложная аналитика без лишних JOIN’ов

История о том, как LEFT JOIN превратился в INNER JOIN, но никто этого не заметил.

Был у меня запрос. Красивый, аккуратный, должен был выводить все заказы, даже те, которые НЕ в статусе 'paid'.

SELECT *
FROM orders o
LEFT JOIN payments p ON p.order_id = o.id
WHERE p.status = 'paid';

Смотрю — LEFT JOIN.
Думаю: ну всё правильно, хотим же заказы, даже если оплаты нет.

Запрос работает. Данные возвращает. Прод живёт.

Проходит время.

Приходит вопрос:
— А почему у нас пропали заказы без оплаты? У нас что все заказы только оплаченные?

Я открываю запрос, смотрю ещё раз.
LEFT JOIN — есть.
Вроде всё логично.

А потом PostgreSQL тихо так подсказывает:
— Друг, ты уверен, что это LEFT JOIN?

Я отвечаю:
— Уверен, написано же LEFT JOIN !!

Он продолжает:
— У тебя в запросе условие WHERE p.status = 'paid' —
это не фильтр таблицы orders.
Это фильтр результата после JOIN.

— И для строк, где оплаты нет,
p.status равен NULL.

— А NULL = 'paid' — это не TRUE.
Это ничего. Поэтому я просто выкидываю эти строки.

В этот момент LEFT JOIN:
— Я вообще-то был левым…

А WHERE отвечает:
— Был. Теперь ты INNER.

Исправление оказалось простым, условие нужно было перенести в LEFT JOIN:

SELECT *
FROM orders o
LEFT JOIN payments p ON p.order_id = o.id AND p.status = 'paid';

Вывод:
LEFT JOIN — не гарантия того, что строки сохранятся.
Одно условие в WHERE — и вы сами превращаете его в INNER JOIN.

PostgreSQL не ошибается.
Он просто выполняет то, что вы написали.
Даже если вы написали это «логично».

🎄 Друзья, вот и подходит к концу 2025 год.

Предлагаю оставить в нём всё лишнее:
ошибки, сомнения, неудачные запросы.

А всё нужное и ценное — опыт, знания, идеи и желание развиваться —
смело забираем с собой в 2026 год.

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

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

С наступающим Новым 2026 годом! 🚀
Пусть он будет сильным, продуктивным и по-настоящему вашим.

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

ИИ не является разумом в человеческом смысле. У него нет желаний, целей, намерений, понимания смысла или ответственности за последствия. Он не думает и не выбирает — он анализирует прошлое, находит закономерности и делает прогнозы. Любое «решение» ИИ — это не выбор, а статистическое предположение, основанное на исторических данных и совпадениях похожих ситуаций. Он всегда смотрит назад, даже когда кажется, что он смотрит в будущее.

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

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

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

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

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

Будут ли потери и болезненные изменения? Да. Профессии будут меняться, привычные роли исчезать, а многим придётся переучиваться. Но выиграют не самые умные и не самые технически подкованные, а самые гибкие — те, кто умеет учиться, мыслить и общаться.

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

Ребята, всем привет 👋
Наконец-то добрался до запуска — сайт с SQL-тренажёрами и тестами по PostgreSQL вышел в продакшн 🚀

Сейчас на платформе:

- базовый SQL-тренажёр
- продвинутый SQL-тренажёр
- несколько тестов по SQL и PostgreSQL

Сейчас это всё бесплатно, нужно только зарегистрироваться на сайте.

Если вам интересно потренироваться в решении SQL-задач или проверить свои знания — буду рад, если заглянете и попробуете тренажёры.

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

Также есть отдельная группа в ТГ:

- ветки для каждого продукта
- общая ветка
- обратная связь

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

Платформа будет дальше развиваться и расширяться — в планах вырастить её в полноценную, увлекательную образовательную платформу не только по SQL.

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

Спасибо всем, кто поддержит 🙏

Ссылка на сайт: https://smartgatepro.ru/
Ссылка на группу сайта в ТГ: t.me/smartgate_pro

Нужно вывести все заказы, кроме оплаченных.

Запрос выглядит предельно логично:

SELECT *
FROM orders
WHERE status != 'paid';

В голове всё быстро:

— paid не нужен → выкидываем Alice и Evan
— shipped, cancelled, returned — подходят
— NULL? Ну, вроде бы тоже не paid

В уме получается:
Bob ✔️
Charlie ✔️
Diana ✔️
Frank ✔️
Grace ✔️

Итого: 5 строк.

Запрос выполняется.

PostgreSQL возвращает… 3 строки.

Без Diana.
Без Frank.

Два заказа просто исчезли.

В этот момент PostgreSQL спокойно уточняет:

— А ты уверен, что NULL != 'paid' — это TRUE?

Потому что для PostgreSQL:

NULL != 'paid'

— это не TRUE
— и не FALSE
— это UNKNOWN

А в WHERE проходят только строки, где условие TRUE.

NULL не «не равно».
Он просто неизвестен.

И WHERE отвечает:

— Не уверен? Значит, эти строки не берём в результат.

Вывод неприятный, но полезный:

!= не означает «всё, кроме этого значения».
С NULL это правило ломается.

PostgreSQL не теряет строки.
Он просто выполняет запрос буквально.

Даже если в голове всё выглядело очевидно.

Частая ошибка мышления 👇
«Если запрос работает — значит он хороший»

Запрос может быть:
– синтаксически правильным
– логически верным
– возвращать нужный результат

И при этом быть плохим.

Почему? В общих чертах.

🔹 Он делает больше работы, чем нужно
Запрос может сначала собрать «лишнее», а потом отбросить.
Результат тот же, а усилий — больше.

🔹 Он неудобен для базы данных
Некоторые формулировки выглядят логично для человека,
но неудобны для PostgreSQL.
База не «понимает смысл» — она выполняет шаги.

🔹 Он плохо читается
Если запрос сложно понять с первого раза,
его сложно поддерживать, менять и оптимизировать.
А значит, проблемы — вопрос времени.

🔹 Он хорошо работает только сейчас
На небольших таблицах разницы почти не видно.
Но при росте данных такой запрос начинает резко «дорожать».

Главная мысль простая:
👉 Правильный результат ещё не делает запрос хорошим

Хороший запрос — это не только что он вернул,
но и насколько аккуратно он это сделал:
– без лишней работы
– понятно для человека
– спокойно при росте данных

И именно здесь начинается взрослая работа с SQL на уровне мышления.