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

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

Previous
From: Robert Haas
Date:
Subject: Re: Damage control for planner's get_actual_variable_endpoint() runaway
Next
From: Tom Lane
Date:
Subject: Re: Damage control for planner's get_actual_variable_endpoint() runaway