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

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: Damage control for planner's get_actual_variable_endpoint() runaway
Дата
Msg-id CA+TgmoaaxZmLqoTt1=e5qPEJrY8b57meCa5C3xGi5CwVgTNRXw@mail.gmail.com
обсуждение исходный текст
Ответ на Re: Damage control for planner's get_actual_variable_endpoint() runaway  (Tom Lane <tgl@sss.pgh.pa.us>)
Ответы Re: Damage control for planner's get_actual_variable_endpoint() runaway  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Tue, Nov 22, 2022 at 11:35 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Simon Riggs <simon.riggs@enterprisedb.com> writes:
> > New patch version reporting for duty, sir. Please take it from here!
>
> Why the CHECK_FOR_INTERRUPTS?  I'd supposed that there's going to be
> one somewhere down inside the index or heap access --- do you have
> reason to think there isn't?
>
> Is it appropriate to count distinct pages, rather than just the
> number of times we have to visit a heap tuple?  That seems to
> complicate the logic a good deal, and I'm not sure it's buying
> much, especially since (as you noted) it's imprecise anyway.

FWW, the same question also occurred to me. But after mulling it over,
what Simon did seems kinda reasonable to me. Although it's imprecise,
it will generally cause us to stop sooner if we're bouncing all over
the heap and be willing to explore further if we're just hitting the
same heap page. I feel like that's pretty reasonable behavior.
Stopping early could hurt, so if we know that continuing isn't costing
much, why not?

-- 
Robert Haas
EDB: http://www.enterprisedb.com



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

Предыдущее
От: Bruce Momjian
Дата:
Сообщение: Re: New docs chapter on Transaction Management and related changes
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Damage control for planner's get_actual_variable_endpoint() runaway