Плановые операции: врач снова крайний?

Представьте: дежурство в обычной областной больнице. Хирург открывает новости — губернатор заявляет, что плановые операции надо делать максимум через месяц. Для онкологии обещан отдельный быстрый путь.

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

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

Где сегодня граница профессиональной и личной ответственности врача, если реальный поток пациентов не бьётся с красивыми сроками в постановлениях и заявлениях?

И что будет, когда первый пациент из очереди придёт не к организатору здравоохранения, а прямо в ваш кабинет с распечаткой новости и вопросом: «Доктор, а почему у меня не так?»

https://ria.ru/20251211/rossiya-2061518671.html?ysclid=mjk3h...

Взято с основного технического канала Postgres DBA (возможны правки в исходной статье).

Предисловие

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

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

relname | n_live_tup

bookings | 7113192

demo=# \d bookings.bookings

Unlogged table "bookings.bookings"

Column | Type | Collation | Nullable | Default

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

book_ref | character varying(6) | | not null |

book_date | timestamp with time zone | | not null |

total_amount | numeric(10,2) | | not null |

Indexes:

"bookings_pkey" PRIMARY KEY, btree (book_ref)

"idx_bookings_book_date" btree (book_date)

Referenced by:

TABLE "tickets" CONSTRAINT "tickets_book_ref_fkey" FOREIGN KEY (book_ref) REFERENCES bookings(book_ref)

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

SELECT * FROM bookings.bookings WHERE book_ref LIKE 'scenario5-TEST%';

План выполнения тестового запроса cost=1000.00..102491.48

EXPLAIN ( ANALYZE , COSTS , SETTINGS , BUFFERS , SUMMARY , MEMORY )

SELECT * FROM bookings.bookings WHERE book_ref LIKE 'scenario5-TEST%';

Gather (cost=1000.00..102491.48 rows=35566 width=42) (actual time=519.574..533.363 rows=0 loops=1)

Workers Planned: 1

Workers Launched: 1

Buffers: shared hit=45632

-> Parallel Seq Scan on bookings (cost=0.00..97934.88 rows=20921 width=42) (actual time=515.346..515.346 rows=0 loops=2)

Filter: ((book_ref)::text ~~ 'scenario5-TEST%'::text)

Rows Removed by Filter: 3556596

Buffers: shared hit=45632

Settings: jit = 'off', generic_plan_fuzz_factor = '0.9', random_page_cost = '1.1', effective_io_concurrency = '300', temp_buffers = '14MB', max_parallel_workers_per_gather = '1', max_parallel_workers = '16', effective_cache_size = '6GB'

, work_mem = '32MB', search_path = 'bookings, "$user", public'

Planning:

Buffers: shared hit=6

Memory: used=12kB allocated=24kB

Planning Time: 0.194 ms

Execution Time: 533.402 ms

(14 rows)

Необходимо оптимизировать таблицу, для ускорения запросов по условию WHERE book_ref LIKE 'XXX%';

Почему индекс не используется?

Индекс bookings_pkey — уникальный B-tree индекс по book_ref

Он идеален для точных совпадений (=) или для поиска по префиксу, если количество совпадающих строк мало.
Однако в данном случае: book_ref LIKE 'scenario5-TEST%' — это префиксный поиск.

Планировщик выбирает Seq Scan, потому что он оценивает, что 7 113 192 строк из 7 113 192 (все строки) подходят под фильтр

В выводе EXPLAIN указано: Rows Removed by Filter: 3556596

Это означает, что в таблице всего 7 113 192 строк, и все они прошли через фильтр book_ref LIKE 'scenario5-TEST%', но ни одна не удовлетворила условию — то есть в таблице нет ни одной строки, начинающейся с 'scenario5-TEST'.

То есть:

• Фильтр book_ref ~~ 'scenario5-TEST%' применяется ко всем строкам.

• Он отсеивает все строки (Rows Removed by Filter = 7 113 192).

• Но индекс не помогает, потому что нет ни одной строки, соответствующей шаблону — и планировщик не знает этого заранее.

Ключевой момент:

Планировщик не знает, что шаблон 'scenario5-TEST%' не совпадает ни с одной строкой. Он оценивает статистику:

• Если бы было 100 строк, соответствующих шаблону — индекс использовался бы.

• Если бы было 1 000 000 строк — индекс мог бы использоваться, но с высокой стоимостью.

• Но если все строки проходят через фильтр (и при этом ни одна не подходит), то планировщик не видит смысла использовать индекс, потому что: Индекс требует доступа к индексу, затем доступа к таблице (heap) для проверки book_ref.
  При отсутствии совпадений — это двойная работа: сначала читать индекс, потом проверять каждую строку в таблице — и всё равно ничего не удалить.
  Seq Scan — это просто последовательное чтение таблицы, и если все строки нужно проверить, то это оптимально.

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

Потому что PostgreSQL планировщик выбирает план с минимальной оценкой стоимости.
Для LIKE с префиксом ('prefix%') B-tree индекс может быть использован, но только если: Количество совпадающих строк мало (обычно < 5–10% от таблицы).
Или если статистика показывает, что шаблон редок.
В данном случае: Шаблон 'scenario5-TEST%' не совпадает ни с одной строкой.
Планировщик не знает этого заранее — он оценивает по статистике.
Он предполагает, что шаблон может совпадать с некоторым количеством строк, но не с большинством.

Однако, поскольку в таблице нет таких строк, и фильтр применяется ко всем, то Seq Scan оказывается дешевле, чем: Чтение индекса (чтобы найти потенциальные совпадения), затем чтение таблицы по TID (для проверки book_ref).
Индекс не помогает, потому что он не уменьшает количество строк, которые нужно проверить — их всё равно 7 млн.

Как использовать индекс? Создать функциональный индекс для LIKE-запросов

CREATE INDEX idx_bookings_book_ref_pattern ON bookings.bookings (book_ref text_pattern_ops);

Этот индекс оптимизирован для LIKE с префиксом и может быть использован даже при больших объемах, если планировщик оценит его эффективность.

1.Проверить текущую локаль:

SHOW lc_collate;

Если результат — C или POSIX, то индекс bookings_pkey уже может использоваться для LIKE 'prefix%'.
Если результат — ru_RU.UTF-8, en_US.UTF-8 и т.п. — индекс text_pattern_ops обязателен.

demo=# SHOW lc_collate;

lc_collate

------------

ru_RU.utf8

(1 row)

2.Изменить тип столбца на varchar

• text_pattern_ops — операторный класс, предназначенный для text и varchar.

• character(n) (или bpchar) — это фиксированная строка с пробелами-заполнителями, и не является бинарно-приводимой к text в контексте индексирования.

• Поэтому PostgreSQL не позволит создать индекс с text_pattern_ops на столбце типа character(n).

book_ref  | character(6)

demo=# \d bookings.bookings

Unlogged table "bookings.bookings"

Column  |  Type  | Collation | Nullable | Default

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

book_ref  | character(6)  |  | not null |

book_date  | timestamp with time zone |  | not null |

total_amount | numeric(10,2)  |  | not null |

Indexes:

"bookings_pkey" PRIMARY KEY, btree (book_ref)

"idx_bookings_book_date" btree (book_date)

Referenced by:

TABLE "tickets" CONSTRAINT "tickets_book_ref_fkey" FOREIGN KEY (book_ref) REFERENCES bookings(book_ref)

Проверка перед изменением

Убедитесь, что в столбце нет значений с завершающими пробелами (что маловероятно для book_ref):
SELECT book_ref, length(book_ref), char_length(book_ref)
FROM bookings.bookings
WHERE length(book_ref) != char_length(book_ref)
LIMIT 10;

Если запрос возвращает 0 строк — значит, все значения без лишних пробелов, и переход на varchar безопасен.

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

Тип character(n) (или bpchar) в PostgreSQL — это фиксированная строка, которая дополняется пробелами до указанной длины. Например:

• Если book_ref имеет значение 'ABC123' и тип character(6) — хранится как 'ABC123' (без изменений).

• Если book_ref имеет значение 'AB' и тип character(6) — хранится как 'AB ' (с четырьмя завершающими пробелами).

Запрос проверяет, не содержатся ли в столбце book_ref некорректные значения с завершающими пробелами, которые могут остаться после смены типа с character(n) на varchar(n).
Это критически важно для сохранения целостности данных, особенно в системах, где book_ref используется как первичный ключ или внешний ключ.

Рекомендация: Всегда выполнятm проверку перед изменением типа character(n) → varchar(n), даже если считается, что "пробелов не может быть" — в базах данных всегда НУЖНО проверять данные, а не предполагайте их корректность.

Изменить тип столбца на varchar(6);

ALTER TABLE bookings.bookings ALTER COLUMN book_ref TYPE varchar(60);

book_ref | character varying(60)

demo=# \d bookings.bookings

Unlogged table "bookings.bookings"

Column | Type | Collation | Nullable | Default

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

book_ref | character varying(60) | | not null |

book_date | timestamp with time zone | | not null |

total_amount | numeric(10,2) | | not null |

Indexes:

"bookings_pkey" PRIMARY KEY, btree (book_ref)

"idx_bookings_book_date" btree (book_date)

Referenced by:

TABLE "tickets" CONSTRAINT "tickets_book_ref_fkey" FOREIGN KEY (book_ref) REFERENCES bookings(book_ref)

3.Создать индекс idx_bookings_book_ref_pattern

CREATE INDEX idx_bookings_book_ref_pattern ON bookings.bookings (book_ref text_pattern_ops);

demo=# \d bookings.bookings

Unlogged table "bookings.bookings"

Column | Type | Collation | Nullable | Default

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

book_ref | character varying(60) | | not null |

book_date | timestamp with time zone | | not null |

total_amount | numeric(10,2) | | not null |

Indexes:

"bookings_pkey" PRIMARY KEY, btree (book_ref)

"idx_bookings_book_date" btree (book_date)

"idx_bookings_book_ref_pattern" btree (book_ref text_pattern_ops)

Referenced by:

TABLE "tickets" CONSTRAINT "tickets_book_ref_fkey" FOREIGN KEY (book_ref) REFERENCES bookings(book_ref)

4. Проверить план выполнения

cost=472.78..27152.99

EXPLAIN ( ANALYZE , COSTS , SETTINGS , BUFFERS , SUMMARY , MEMORY )

SELECT * FROM bookings.bookings WHERE book_ref LIKE 'scenario5-TEST%';

Bitmap Heap Scan on bookings (cost=472.78..27152.99 rows=35566 width=42) (actual time=0.043..0.044 rows=0 loops=1)

Filter: ((book_ref)::text ~~ 'scenario5-TEST%'::text)

Buffers: shared read=3

I/O Timings: shared read=0.021

-> Bitmap Index Scan on idx_bookings_book_ref_pattern (cost=0.00..463.89 rows=35566 width=0) (actual time=0.037..0.038 rows=0 loops=1)

Index Cond: (((book_ref)::text ~>=~ 'scenario5-TEST'::text) AND ((book_ref)::text ~<~ 'scenario5-TESU'::text))

Buffers: shared read=3

I/O Timings: shared read=0.021

Settings: jit = 'off', generic_plan_fuzz_factor = '0.9', random_page_cost = '1.1', effective_io_concurrency = '300', temp_buffers = '14MB', max_parallel_workers_per_gather = '1', max_parallel_workers = '16', effective_cache_size = '6GB'

, work_mem = '32MB', search_path = 'bookings, "$user", public'

Planning:

Buffers: shared hit=12 read=1

I/O Timings: shared read=0.027

Memory: used=16kB allocated=40kB

Planning Time: 0.301 ms

Execution Time: 0.077 ms

(15 rows)

Результат

Исходный план выполнения:

• Gather (cost=1000.00..102491.48 rows=35566 width=42) (actual time=519.574..533.363 rows=0 loops=1)

• Execution Time: 533.402 ms

Оптимизированный план выполнения:

• Bitmap Heap Scan on bookings (cost=472.78..27152.99 rows=35566 width=42) (actual time=0.043..0.044 rows=0 loops=1)

• Execution Time: 0.077 ms

Последние пару лет ИИ на производстве стал чем‑то вроде обязательного пункта повестки. Про него говорят собственники, его ждут от команд, его упоминают в стратегиях «на будущее». Часто – с молчаливым ожиданием, что ИИ сам по себе наведет порядок: ускорит процессы, сократит ручной труд, сделает бизнес более управляемым.

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

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

Как выглядел запрос клиента

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

Разговор начался с осторожным интересом и сомнением:

«Давайте подумаем, где мы можем внедрить ИИ, чтобы он дал результат».

За этой формулировкой стояло вполне понятное состояние. С одной стороны – ощущение, что бизнес упирается в потолок эффективности. С другой – непонимание, за что именно хвататься.

На старте ни собственник, ни команда не могли четко сформулировать:

– какие конкретные проблемы должен решить ИИ;
– где компания реально теряет деньги или время;
– какие решения сейчас принимаются скорее «по опыту», чем на основе системы.

При этом внутреннее напряжение уже накапливалось. Много ручных операций. Сильная зависимость от отдельных людей и их экспертизы. Разные подразделения опираются на разные цифры. Эффект от изменений часто становится понятен слишком поздно – когда что-то исправлять уже дорого или сложно.

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

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

Почему нельзя начинать с ИИ

На старте кажется, что все и так понятно: где‑то много ручного труда, где‑то не хватает прозрачности, где‑то люди перегружены. Хочется сразу идти в решения.

Но в реальности у каждого блока своя картина происходящего. Производство видит одни узкие места. Финансы – другие. Коммерция – третьи. Если в этот момент начинать внедрять ИИ точечно, под запрос одного отдела, результат почти всегда получается локальным и плохо масштабируемым.

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

Что мы сделали вместо этого

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

Первым шагом стали разговоры с руководителями всех ключевых блоков: производства, финансов, КБ, коммерции, логистики. Не презентации и не сбор идей «что можно автоматизировать», а подробный разбор реальной управленческой рутины.

Мы спрашивали:

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

Эти разговоры быстро показали: запрос на ИИ – это следствие, а не причина. Основные проблемы лежат в несогласованных данных, ручных пересчетах, разрывах между подразделениями.

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

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

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

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

Где ИИ действительно дал эффект (а где – нет)

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

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

ИИ появился только в тех точках, где:

– есть повторяющаяся операция;
– задействовано несколько человек;
– цена ошибки ощутима;
– автоматизация дает понятный экономический эффект.

Один из таких примеров – склад.

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

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

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

Важно, что в других блоках ИИ сознательно не внедряли. Потому что сначала нужно было привести в порядок данные, логику расчетов и саму управленческую модель. Без этого любые «умные» инструменты не дали бы устойчивого результата.

Почему так сработает не у всех

После подобных историй часто возникает желание повторить: «значит, нам тоже нужен ИИ».

Но здесь важно быть честными. ИИ не станет волшебной палочкой, если:

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

В такой ситуации ИИ либо не даст эффекта, либо создаст новые точки сложности.

Как работать с ИИ, чтобы он действительно давал эффект

Рабочий подход почти всегда начинается не с технологий, а с управления:

1. Понять, какие решения в бизнесе реально влияют на деньги.

2. Разобраться, где эти решения принимаются вслепую или с запозданием.

3. Навести порядок в процессах и данных.

4. И только потом использовать ИИ – там, где он дает измеримый результат.

Именно такой подход мы и называем цифровой стратегией.

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

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

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

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