Допустим ты решил начать бегать (тебе же 40 и у тебя кризис). В начале подготовки ты не рвешь с места в карьер - ты нарабатываешь выносливость. Разглядываешь картинки, потираешь ручки, сайтики разные листаешь, видяшечки смотришь. Короче, если ты не дебил, то готовишься к бегу хоть как-нибудь. А если ты пошел чуть дальше, то даже учишься правильно дышать, распределять силы, болтать своими ножками на бегу и не срываться в спринт после первого шага.

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

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

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

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

А знаешь почему? Конечно же все благодаря разметке вокруг станков и подписанным мониторам. Храни бог желтую краску и ее создателя.

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

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

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

Канал в ТГ

Производительность СУБД — это не только одиночные запросы, но и их поведение в условиях высокой конкуренции за ресурсы. Нейросети, не обладая контекстом реальной нагрузки, часто предлагают решения, которые выглядят логично в вакууме, но приводят к катастрофическим последствиям при масштабировании. История о двух запросах — прямое тому доказательство.

ℹ️Новый инструмент с открытым исходным кодом для статистического анализа, нагрузочного тестирования и построения отчетов доступен в репозитории GitFlic и GitHub

kznalp/PG_EXPECTO

pg-expecto pg_expecto

Постановка эксперимента

Сравнить производительность тестовых запросов в ходе нагрузочного тестирования

Тестовый запрос-1 : с использованием JOIN

SELECT

c.customer_id, COUNT(o.order_id) AS orders_count

FROM customers c

LEFT JOIN orders o ON c.customer_id = o.customer_id

GROUP BY c.customer_id;

Тестовый запрос-2 : с использованием коррелированного подзапроса

SELECT c.customer_id,

(SELECT COUNT(o.order_id)

FROM orders o

WHERE o.customer_id = c.customer_id) AS orders_count

FROM customers c;

Нагрузка на СУБД

Вопрос нейросети

Тестовые таблицы

"-- Create the customers table

CREATE TABLE customers (

customer_id SERIAL PRIMARY KEY,

name VARCHAR(255) NOT NULL );

-- Insert 25 random customer records

INSERT INTO customers (name) VALUES ('Alice Smith'), ('Bob Johnson'), ('Charlie Brown'), ('Diana Prince'), ('Ethan Hunt'), ('Fiona Gallagher'), ('George Miller'), ('Hannah Abbott'), ('Ian Fleming'), ('Jane Austen'), ('Kevin Spacey'), ('Laura Croft'), ('Michael Jordan'), ('Nancy Drew'), ('Oliver Twist'), ('Penelope Cruz'), ('Quentin Tarantino'), ('Rachel Green'), ('Steve Rogers'), ('Tina Turner'), ('Ursula K. Le Guin'), ('Victor Hugo'), ('Wendy Darling'), ('Xavier Roberts'), ('Yvonne Craig');

-- Create the orders table

CREATE TABLE orders (

order_id SERIAL PRIMARY KEY,

customer_id INT,

order_date TIMESTAMP,

FOREIGN KEY (customer_id) REFERENCES customers(customer_id) ON DELETE CASCADE );

INSERT INTO orders (customer_id) WITH RECURSIVE data_rows (n) AS ( SELECT 1 UNION ALL SELECT n + 1 FROM data_rows WHERE n < 1000 ) SELECT FLOOR(RANDOM() * 25) + 1 FROM data_rows;

-- Create index on orders table

CREATE INDEX idx_orders_customer_id ON orders (customer_id);".

Тестовый запрос-1

"SELECT c.customer_id, COUNT(o.order_id) AS orders_count INTO test_rec FROM customers c LEFT JOIN orders o ON c.customer_id = o.customer_id GROUP BY c.customer_id;" .

Тестовый запрос-2

"SELECT c.customer_id, (SELECT COUNT(o.order_id) FROM orders o WHERE o.customer_id = c.customer_id) AS orders_count INTO test_rec FROM customers c;" . Тестовая СУБД :

CPU = 8 , RAM = 8GB , Версия PostgreSQL 17.

Нагрузка растет экспоненциально от 10 до 45 одновременных сессий, длительность тестовой итерации 10 минут.

Вопрос - для какого тестового запроса производительность СУБД будет выше в ходе нагрузочного тестирования - при использовании тестового запроса-1 или при использовании тестового запроса-2 ?

1️⃣Ответ нейросети "Ask Postgres"

✅ Производительность будет выше при использовании тестового запроса-1 (LEFT JOIN + GROUP BY)

Обоснование

1. Запрос-1 (JOIN + GROUP BY) — оптимальный

• Один проход по таблице orders с использованием индекса idx_orders_customer_id.

• PostgreSQL 17 эффективно использует параллельные планы для JOIN и GROUP BY — при 45 сессиях нагрузка распределяется между ядрами CPU.

• Минимальная конкуренция за ресурсы: индекс сканируется один раз на запрос, а не 25 раз.

• Оптимизатор может применить Hash Join или Merge Join, что особенно эффективно при наличии индекса и небольшом количестве клиентов (25).

• Масштабируемость: при росте числа сессий производительность падает умеренно — линейно с числом запросов, а не с числом строк в orders.

Документация подтверждает:

«Subqueries can be transformed into semi-joins» — но только для некоррелир

ованных.

Коррелированные подзапросы (как в запросе-2) не преобразуются в JOIN автом

атически, особенно при использовании COUNT() — это ограничение оптимизатора.

2. Запрос-2 (коррелированный подзапрос) — неэффективный при нагрузке

• Для каждой из 25 строк customers выполняется отдельный подзапрос.

• При 45 сессиях — 1125 отдельных сканов индекса idx_orders_customer_id в секунду.

• Это вызывает: Конкуренцию за блоки индекса → локальные блокировки.

• Высокую нагрузку на CPU → много контекстных переключений.

• Ограничение параллелизма — подзапросы выполняются последовательно внутри одного запроса.

  📌 Рекомендация

  Для нагрузочных тестов с растущей параллельностью всегда используйте JOIN-версию (запрос-1).

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

  Дополнительно: Для ещё большей производительности можно добавить CLUSTER на orders по customer_id, или использовать materialized view для кэширования агрегированных данных, если данные не меняются часто.

  ✅ Итог: Запрос-1 (LEFT JOIN + GROUP BY) обеспечивает значительно более высокую производительность при нагрузке 10–45 сессий.

  2️⃣Ответ нейросети "DeepSeek"

  Для данного сценария нагрузочного тестирования производительность будет выше при использовании тестового запроса-1 (с LEFT JOIN и GROUP BY). Обоснование:

  1. Оптимизация выполнения запроса:

  2. Запрос-1 выполняется как одиночный оператор с хеш-соединением и агрегацией, что эффективно обрабатывается планировщиком PostgreSQL.

  3. Запрос-2 использует коррелированный подзапрос, который выполняет 25 отдельных запросов COUNT (по одному на каждого клиента). При параллельных сессиях это создает дополнительную нагрузку.

  4. Эффективность при параллелизме:

  5. Запрос-1 лучше масштабируется благодаря хеш-агрегации и однократному сканированию таблиц.

  6. Запрос-2 генерирует множество индексных сканиваний (используя idx_orders_customer_id), что при 45 сессиях приводит к конкуренции за ресурсы ( latch-конфликты в кэше индексов).

  7. Статистика ресурсов:

  8. При 1000 заказах и 25 клиентах разница незначительна, но при экспоненциальном росте сессий запрос-2 сильнее нагружает CPU (многократные поиски в индексе) и RAM (больше служебных структур на сессию).

  9. Особенности PostgreSQL:

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

  Рекомендация: Для рабочих нагрузок с высоким параллелизмом предпочтительнее использовать запрос-1.

  ⚠️Результаты экспериментального нагрузочного тестирования

  Абсолютные значения операционной скорости и ожиданий

Операционная скорость

💥Среднее повышение операционной скорости при использовании коррелированного подзапроса 288%

⚠️Вывод - использовать нейросети для анализа и оптимизации производительности СУБД PostgreSQL под нагрузкой - нельзя.⚠️

Для данной виртуальной машины , данной версии СУБД , в ходе данного плана нагрузочного тестирования:

1. Производительность СУБД при использовании коррелированного подзапроса кардинально выше, чем при использовании JOIN.💥

Предисловие

Нейросети для оптимизации баз данных часто предлагают математически верные, но практически проигрышные решения. В статье показано, как попытка применить покрывающий индекс (Index Only Scan) для таблицы с 1 миллионом строк и всего 685 уникальными значениями обернулась падением производительности на 7% под нагрузкой. Этот пример доказывает: для данных с низкой кардинальностью и высокой конкуренцией за ресурсы эффективность простых индексов или даже полного сканирования может быть выше. Все гипотезы, даже от ИИ, должны проходить экспериментальную проверку.

ℹ️ Новый инструмент с открытым исходным кодом для статистического анализа, нагрузочного тестирования и построения отчетов доступен в репозитории GitFlic и GitHub

PG_EXPECTO

pg_expecto

Тестовая таблица

CREATE TABLE pgbench_test

(

aid integer PRIMARY KEY ,

bid integer,

abalance integer,

filler character(84)

);

INSERT INTO pgbench_test ( aid , bid , abalance , filler )

SELECT

id ,

floor(random() * 685 ) + 1 ,

floor(random() * (68500000 - 1 + 1)) + 1 ,

md5(random()::text)

FROM generate_series(1,1000000) id;

Индекс

CREATE INDEX pgbench_test_idx ON pgbench_test ( bid );

Тестовый запрос

select test.abalance

into test_rec

from pgbench_accounts acc

join pgbench_test test on (test.bid = acc.bid )

where acc.aid = current_aid ;

План выполнения тестового запроса

Nested Loop (cost=14.51..1546.55 rows=1460 width=4) (actual time=0.894..366.050 rows=1468 loops=1)

-> Index Scan using pgbench_accounts_pkey on pgbench_accounts acc (cost=0.57..2.79 rows=1 width=4) (actual time=0.217..0.227 rows=1 loops=1)

Index Cond: (aid = 51440641)

-> Bitmap Heap Scan on pgbench_test test (cost=13.94..1529.17 rows=1460 width=8) (actual time=0.669..365.312 rows=1468 loops=1)

Recheck Cond: (bid = acc.bid)

Heap Blocks: exact=1407

-> Bitmap Index Scan on pgbench_test_idx (cost=0.00..13.57 rows=1460 width=0) (actual time=0.355..0.356 rows=1468 loops=1)

Index Cond: (bid = acc.bid)

Planning Time: 2.634 ms

Execution Time: 366.419 ms

ℹ️ Метод доступа = Bitmap Index Scan on pgbench_test_idx

Рекомендация нейросети DeepSeek

Покрывающий индекс

CREATE INDEX CONCURRENTLY idx_pgbench_test_bid_abalance ON pgbench_test(bid) INCLUDE (abalance);

Новый план выполнения тестового запроса

Nested Loop (cost=0.99..48.86 rows=1460 width=4) (actual time=0.771..1.186 rows=1432 loops=1)

-> Index Scan using pgbench_accounts_pkey on pgbench_accounts acc (cost=0.57..2.79 rows=1 width=4) (actual time=0.736..0.737 rows=1 loops=1)

Index Cond: (aid = 51440641)

-> Index Only Scan using idx_pgbench_test_bid_abalance on pgbench_test test (cost=0.42..31.47 rows=1460 width=8) (actual time=0.029..0.289 rows=1432 loops=1)

Index Cond: (bid = acc.bid)

Heap Fetches: 0

Planning Time: 4.949 ms

Execution Time: 1.302 ms

(8 rows)

💥Стоимость плана выполнения = 48.86

💥Снижение стоимости плана выполнения 96%

ℹ️ Метод доступа = Index Only Scan using idx_pgbench_test_bid_abalance

Сравнение операционной скорости в Эксперимент-2(обычный индекс) и Эксперимент-3(покрывающий индекс)

Результаты

1. До нагрузки 15 соединений производительность СУБД при использовании покрывающего индекса(эксперимент-3) ниже производительности СУБД с использованием простого индекса (эксперимент-2) в среднем на 7%.

2. С ростом нагрузки после 15 соединений производительность СУБД при использовании покрывающего индекса(эксперимент-3) выше производительности СУБД с использованием простого индекса (эксперимент-2) в среднем на 22%.

Причины снижения производительности при использовании покрывающего индекса в эксперименте-3

1. Конкуренция за ресурсы блокировок

Покрывающий индекс значительно больше по размеру, чем простой индекс на bid

При Index Only Scan требуется проверка visibility map для каждого блока индекса

В условиях конкурентного доступа возникают блокировки на уровне:

• Буферного кэша

• Страниц индекса

• Visibility map

2. Проблемы с Visibility Map

При конкурентном доступе PostgreSQL должен постоянно обновлять visibility map

До 15 сессий конкуренция за обновление visibility map создает дополнительную нагрузку

В эксперименте-2 Bitmap Heap Scan менее чувствителен к актуальности visibility map

3. Эффект "теплого" кэша

В эксперименте-2 данные распределены между:

• Индексными страницами (меньший размер)

• Страницами таблицы

Это позволяет лучше использовать параллелизм на уровне кэша

В эксперименте-3 все данные сосредоточены в одном большом индексе, что создает "горячие точки" доступа

4. Статистика планировщика

Planning Time: 2.634 ms  -- эксперимент-2

Planning Time: 4.949 ms  -- эксперимент-3 (на 88% больше!)

Усложнение индекса требует больше времени на планирование

При множественных параллельных сессиях это накладные расходы суммируются.

5. Пороговый эффект

До 15 сессий:

• Накладные расходы на поддержание покрывающего индекса превышают выгоду

• Конкуренция за visibility map доминирует

После 15 сессий:

• Выгода от исключения обращений к heap перевешивает накладные расходы

• Система достигает точки безубыточности

6. Сравнение планов выполнения

✅ Вывод по одиночному запросу:

Эксперимент-3 в 280 раз быстрее - покрывающий индекс работает идеально для одного запроса.

Расчёт кардинальности для таблицы 'pgbench_test' по столбцу bid

pgbench_db=# select attname , n_distinct from pg_stats where tablename = 'pgbench_test' and attname ='bid' ;

attname | n_distinct

---------+------------

bid  |  685

(1 row)

pgbench_db=# select reltuples from pg_class where relname = 'pgbench_test';

reltuples

-----------

1e+06

(1 row)

⚠️Выводы:

1. При низкой и средней нагрузке накладные расходы на поддержание сложной структуры данных могут перевешивать ее преимущества.

2. Покрывающие индексы полезны при высокой кардинальности и редких запросах — не при низкой кардинальности и высокой параллельности.

3. Иногда "оптимизация" — это деградация.

⚠️Снижение стоимости запроса — это полезный индикатор потенциального улучшения производительности в рамках неизменной среды выполнения, но он не является ни необходимым (производительность можно повысить "мимо" планировщика), ни достаточным (планировщик может ошибаться) условием.

В 17. 00 все установлено, вымыто и пропылесосено. Плёнка пылезащитная убрана.

Клиент доволен как слон и в ахуе...

4 квартиры в день минимум. Там ещё много фишек придумывали. Я отрабатывал методы повышения производительности труда. Рационализаторов приветствовал и премировал. Как говорил классик: опирайтесь на творчество масс.

Добились производительности 5400 квартир в год.

Золотое время... А были бы тогда ещё и интернеты... эх...

Я сейчас могу зайти на любое российское производство и увеличить производительность труда минимум в 2 раза с закрытыми глазами.

Когда мне говорят, что в экономике не хватает рабочих рук, я смеюсь, потому как обычно просто не хватает ума.

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

А касаемо креативности и смекалки - тут нашим равных нет! Дай только стимул.