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

From Andres Freund
Subject Re: Damage control for planner's get_actual_variable_endpoint() runaway
Date
Msg-id 20221121215352.exjkeg42nolanl3b@alap3.anarazel.de
Whole thread Raw
In response to Re: 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
Hi,

On 2022-11-21 16:17:56 -0500, Robert Haas wrote:
> But ... what if they're not? Could the index contain a large number of
> pages containing just 1 tuple each, or no tuples at all? If so, maybe
> we can read ten bazillion index pages trying to find each heap tuple
> and still end up in trouble.

ISTM that if you have an index in such a poor condition that a single
value lookup reads thousands of pages inside the index, planner
estimates taking long is going to be the smallest of your worries...

Greetings,

Andres Freund



pgsql-hackers by date:

Previous
From: Andres Freund
Date:
Subject: Re: HOT chain validation in verify_heapam()
Next
From: Corey Huinker
Date:
Subject: Re: psql: Add command to use extended query protocol