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
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 |