Не имеет смысла пытаться инжектить relpages, так как планировщик проверяет фактический размер файла и масштабирует значения пропорционально.

Планировщик не доверяет pg_class.relpages. Он вызывает smgrnblocks(), чтобы считать реальное количество страниц по 8 КБ с диска. У вас таблица занимает 74 страницы на диске, а в pg_class.relpages указано 123 513? Планировщик использует это соотношение, чтобы масштабировать reltuples в соответствии с реальным размером файла. Относительные коэффициенты селективности остаются корректными, форма планов в целом сохраняется, но абсолютные оценки стоимости (cost) становятся неточными.

Для отладки одного запроса это обычно не критично. Но для автоматизированного регрессионного тестирования, где сравниваются значения EXPLAIN cost между запусками, это ломает воспроизводимость. Порог в 2× начинает означать разное, если базовая линия была рассчитана на «фейково» масштабированных данных.

В рамках работы над RegreSQL, автор рад представить расширение pg_regresql, которое решает эту проблему, напрямую внедряясь в планировщик.

https://boringsql.com/posts/regresql-extension/

👉 @SQLPortal