ИИ как опасный советчик

Почему нейросетям нельзя доверять настройку производительности PostgreSQL

📄 Аннотация

Сравнивается эффективность оператора JOIN и коррелированного подзапроса в PostgreSQL в условиях высокой параллельной нагрузки. Экспериментальные данные опровергают универсальные рекомендации нейросетевых моделей и показывают, какие факторы на самом деле определяют производительность.

🎯 Постановка задачи

Вопрос простой: какой паттерн выбрать при высокой параллельной нагрузке на СУБД — JOIN или коррелированный подзапрос? Обе нейросети, которым его задали, ответили одинаково уверенно и одинаково однозначно.

🧪 Детали эксперимента

Сравнивались два запроса, возвращающие один и тот же результат: количество заказов для каждого клиента.

Вариант 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;

План выполнения:

HashAggregate  (cost=35.85..37.25 rows=140 width=12) (actual time=0.622..0.629 rows=25 loops=1)
  Group Key: c.customer_id
  Batches: 1  Memory Usage: 40kB
  ->  Hash Right Join  (cost=13.15..30.85 rows=1000 width=8) (actual time=0.077..0.429 rows=1000 loops=1)
        Hash Cond: (o.customer_id = c.customer_id)
        ->  Seq Scan on orders o  (cost=0.00..15.00 rows=1000 width=8) (actual time=0.035..0.148 rows=1000 loops=1)
        ->  Hash  (cost=11.40..11.40 rows=140 width=4) (actual time=0.028..0.028 rows=25 loops=1)
              Buckets: 1024  Batches: 1  Memory Usage: 9kB
              ->  Seq Scan on customers c  (cost=0.00..11.40 rows=140 width=4) (actual time=0.018..0.021 rows=25 loops=1)

Planning Time: 0.221 ms
Execution Time: 0.787 ms

Вариант 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;

План выполнения:

Seq Scan on customers c  (cost=0.00..1015.20 rows=140 width=12) (actual time=0.093..0.614 rows=25 loops=1)
  SubPlan 1
    ->  Aggregate  (cost=7.16..7.17 rows=1 width=8) (actual time=0.023..0.023 rows=1 loops=25)
          ->  Bitmap Heap Scan on orders o  (cost=1.56..7.06 rows=40 width=4) (actual time=0.007..0.017 rows=40 loops=25)
                Recheck Cond: (customer_id = c.customer_id)
                Heap Blocks: exact=125
                ->  Bitmap Index Scan on idx_orders_customer_id  (cost=0.00..1.55 rows=40 width=0) (actual time=0.004..0.004 rows=40 loops=25)
                      Index Cond: (customer_id = c.customer_id)

Planning Time: 0.145 ms
Execution Time: 0.718 ms

Результат нагрузочного тестирования

При параллельном выполнении измерялась операционная скорость СУБД. Среднее снижение операционной скорости на варианте с JOIN составило 288 % относительно коррелированного подзапроса — то есть подзапрос оказался почти вчетверо быстрее на всём протяжении теста.

График изменения операционной скорости в ходе нагрузочного тестирования.

Обе линии практически горизонтальны — вариант с подзапросом стабильно держится в районе 6,6–7,8 млн, вариант с JOIN — около 1,72–1,79 млн. Разрыв не сокращается с ростом числа точек наблюдения, а к концу теста даже увеличивается: подзапрос ускоряется примерно с 61-й точки, тогда как JOIN медленно проседает.

🔍 Почему рекомендации оказались неверны

⚙️ Что модель не видит в принципе

Откуда берётся ошибка

Обучающие данные моделей — это преимущественно синтетические и упрощённые сценарии:

• небольшие наборы данных (TPC-H, TPC-DS);
• низкая параллельность — от одного до десяти соединений;
• идеализированные индексы;
• отсутствие блокировок и конкуренции за ЦП и ввод-вывод.

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

📋 Заключение