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 3476620.1669141674@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  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
Robert Haas <robertmhaas@gmail.com> writes:
> On Tue, Nov 22, 2022 at 11:35 AM Tom Lane <tgl@sss.pgh.pa.us> wrote:
>> 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?

Fair I guess --- and I did say that I wanted it to be based on number
of pages visited not number of tuples.  So objection withdrawn to that
aspect.

Still wondering if there's really no CHECK_FOR_INTERRUPT anywhere
else in this loop.

            regards, tom lane



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

Предыдущее
От: Robert Haas
Дата:
Сообщение: Re: Damage control for planner's get_actual_variable_endpoint() runaway
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Damage control for planner's get_actual_variable_endpoint() runaway