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

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>, Andres Freund <andres(at)anarazel(dot)de>, pgsql-hackers(at)lists(dot)postgresql(dot)org, Jakub Wartak <jakub(dot)wartak(at)enterprisedb(dot)com>, Alvaro Herrera <alvherre(at)alvh(dot)no-ip(dot)org>, PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: Damage control for planner's get_actual_variable_endpoint() runaway
Date: 2022-11-22 18:27:54
Message-ID: 3476620.1669141674@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> On Tue, Nov 22, 2022 at 11:35 AM Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Tom Lane 2022-11-22 18:44:25 Re: Damage control for planner's get_actual_variable_endpoint() runaway
Previous Message Robert Haas 2022-11-22 18:22:31 Re: Damage control for planner's get_actual_variable_endpoint() runaway