Может ли перенос планировщика Orca в расширение Postgres упростить обновления базы данных?

Переход от интеграции Orca непосредственно в ядро Greengage Database к использованию его как расширения Postgres, направлен на уменьшение внутренней зависимости. Первым шагом стало создание отдельного расширения Orca, подключенного через хук планировщика, что позволило отделить его код от ядра. Для этого потребовалось решение проблем с инициализацией и деинициализацией Orca, которые теперь выполняются отложено, из хука планировщика.
Может ли перенос планировщика Orca в расширение Postgres упростить обновления базы данных?
Изображение носит иллюстративный характер

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

Из ядра были также вынесены специальные функции, такие как enable_xform и gp_opt_version, и перенесены в расширение. Параметр GUC optimizer, отвечавший за включение или выключение Orca, был переопределён для управления общим внешним планировщиком. Также была устранена зависимость от расширения pg_hint_plan.

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


Новое на сайте