Re: Damage control for planner's get_actual_variable_endpoint() runaway - Mailing list pgsql-hackers

From Robert Haas
Subject Re: Damage control for planner's get_actual_variable_endpoint() runaway
Date
Msg-id CA+TgmoaaxZmLqoTt1=e5qPEJrY8b57meCa5C3xGi5CwVgTNRXw@mail.gmail.com
Whole thread Raw
In response to Re: Damage control for planner's get_actual_variable_endpoint() runaway  (Tom Lane <tgl@sss.pgh.pa.us>)
Responses Re: Damage control for planner's get_actual_variable_endpoint() runaway
List 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 by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: New docs chapter on Transaction Management and related changes
Next
From: Tom Lane
Date:
Subject: Re: Damage control for planner's get_actual_variable_endpoint() runaway