Меньше индексов, дешевле запись: как я научил PostgreSQL пересекать B-tree индексы с сохранением порядка

[Fedasiaz]

Это просто невероятно смело. Написать расширение для планировщика PostgreSQL на C, не зная C, — это уровень «миссия невыполнима», но у вас получилось.

Я как раз разрабатываю бота, который автоматически обновляет зависимости и чинит сломанный код через LLM, и на 100% понимаю вашу боль. Главная проблема ИИ-агентов — они генерируют код, который выглядит логично и правдоподобно, но в системных языках (вроде C) это может вылиться в use-after-free или утечки памяти.

Ваш подход к тестированию — это золотой стандарт работы с ИИ. Сборка с --enable-cassert, сравнение результатов через EXCEPT ALL в обе стороны, тесты на конкурентность... Вы сделали ровно то, что нужно: не поверили агенту на слово, а построили детерминированный «забор» из тестов, который невозможно обмануть.

Очень интересен ваш опыт в разделе «Где я не уверен». Когда Claude Code писал этот код, вы сами писали тесты для проверки, или заставляли ИИ их генерировать и потом ревьюили? И как отлавливали ошибки работы с памятью — только через Valgrind/ASan, или ИИ сам справлялся по логам?

[angel_zar]

Я понимаю, что статью можно сгенерировать ИИ. Но комменты генерировать!

[ialeroev]

Это не я)

[ialeroev]

Я задаю направление, а тесты пишет ИИ. Примеры беру из других репозиториев и из кода ядра PostgreSQL: прошу агента найти хорошие расширения и взять оттуда идею и шаблон. Если в алгоритме есть сходство, прошу сравнить решения с кодом, где задача уже решена. Например, с Bitmap в PostgreSQL как с прямым аналогом и с index merge из MySQL. Главное дать ИИ пример решения, дальше он справляется сам. Потом несколько раз прохожусь по коду ревью отдельными ИИ.
Valgrind и ASan не использовал. Память проверяется сборкой с --enable-cassert, которая затирает освобождённую память, и отдельным тестом на её рост при повторных сканах.