Например , нейросеть “Ask Postgres” не знает документацию 🫤 ————— Параметра **\planner_upper_limit_estimation\** в официальной документации Postgres Pro (версии 14–18) и в ядре PostgreSQL **не существует**. Вероятнее всего, вы имеете в виду один из следующих параметров, которые влияют на оценку стоимости выполнения запросов с ограничениями (\LIMIT\), или это специфический параметр из кастомной сборки/расширения, который не задокументирован в общих источниках.

Возможные аналоги и их описание

1. \cursor_tuple_fraction\

Этот параметр определяет долю кортежей, которую планировщик ожидает получить от курсора. * **Значение по умолчанию:** \0.1\ (10%). * **Особенность:** Если вы используете \LIMIT, планировщик может вести себя так, будто нужно вернуть только небольшую часть данных (как при курсоре). * **Влияние:** * Уменьшение значения (например, до \0.01\) заставляет планировщик выбирать планы с **быстрым стартом** (например, \Index Scan\ вместо \Seq Scan\ + \Sort\), даже если они медленнее для полного набора данных. * Увеличение до \1.0\ заставляет планировщик оптимизировать для полного выполнения запроса, игнорируя \LIMIT. * **Риски:** Неверная настройка может привести к выбору неэффективных планов для запросов без явного \LIMIT\ или с большим \LIMIT.

2. \seq_scan_startup_cost_first_row\ (Эксклюзивно Postgres Pro)

Этот параметр добавляет среднюю стоимость получения первой строки к стоимости последовательного сканирования. * **Значение по умолчанию:** \off\ (выключено). * **Особенность:** При включении (\on\) повышает приоритет \Index Scan\ над \Seq Scan, так как увеличивает стоимость “старта” последовательного чтения. * **Влияние:** Полезно для систем с большим количеством запросов с \LIMIT, где важно быстро вернуть первые строки. * **Риски:** Может заставить планировщик выбирать индексы там, где последовательное сканирование было бы эффективнее для больших объемов данных.

3. \enable_extra_transformations\

В Postgres Pro есть параметр, включающий дополнительные трансформации запросов (например, “подтягивание” коррелированных подзапросов). * **Значение по умолчанию:** \on. * **Влияние:** Может менять план выполнения запросов с \LIMIT\ и \OFFSET\ за счет более сложного переписывания дерева запроса.

Рекомендации

1. **Проверьте точное имя параметра.** Возможно, в вашей версии СУБД используется другое название или это параметр из расширения (например, \pg_hint_plan\ или \AQO\), которое вы установили. * Выполните запрос: \\sql SHOW ALL; \\ и найдите параметры, содержащие слова \limit, \estimation\ или \upper. 2. **Если задача — оптимизация запросов с \LIMIT:** * Используйте \cursor_tuple_fraction\ для настройки поведения при курсорах. * Убедитесь, что статистика актуальна (\ANALYZE\), так как планировщик полагается на неё при оценке селективности. * Проверьте наличие индексов на колонках, используемых в \ORDER BY\ и \WHERE. 3. **Если параметр всё же существует в вашей среде:** * Возможно, это внутренний параметр модуля \pgpro_pwr\ или другого расширения Postgres Pro. В этом случае обратитесь к документации конкретного модуля или в техническую поддержку Postgres Pro, предоставив версию СУБД и список установленных расширений. Если вы уточните, для какой именно задачи вы хотите использовать этот параметр (например, “ускорить запросы с LIMIT” или “исправить выбор плана”), я смогу предложить более точное решение.