Re: Damage control for planner's get_actual_variable_endpoint() runaway

Поиск
Список
Период
Сортировка
От Tom Lane
Тема Re: Damage control for planner's get_actual_variable_endpoint() runaway
Дата
Msg-id 3122555.1669044748@sss.pgh.pa.us
обсуждение исходный текст
Ответ на Re: Damage control for planner's get_actual_variable_endpoint() runaway  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: Damage control for planner's get_actual_variable_endpoint() runaway  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> Is there any reason to tie this into page costs? I'd be more inclined
> to just make it a hard limit on the number of pages. I think that
> would be more predictable and less prone to surprising (bad) behavior.

Agreed, a simple limit of N pages fetched seems appropriate.

> And to be honest I would be inclined to make it quite a small number.
> Perhaps 5 or 10. Is there a good argument for going any higher?

Sure: people are not complaining until it gets into the thousands.
And you have to remember that the entire mechanism exists only
because of user complaints about inaccurate estimates.  We shouldn't
be too eager to resurrect that problem.

I'd be happy with a limit of 100 pages.

            regards, tom lane



В списке pgsql-hackers по дате отправления:

Предыдущее
От: "Jonathan S. Katz"
Дата:
Сообщение: Re: heavily contended lwlocks with long wait queues scale badly
Следующее
От: Robert Haas
Дата:
Сообщение: Re: perform_spin_delay() vs wait events