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

From: Andres Freund <andres(at)anarazel(dot)de>
To: Robert Haas <robertmhaas(at)gmail(dot)com>
Cc: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>, 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-21 21:53:52
Message-ID: 20221121215352.exjkeg42nolanl3b@alap3.anarazel.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: 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

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Corey Huinker 2022-11-21 22:02:08 Re: psql: Add command to use extended query protocol
Previous Message Andres Freund 2022-11-21 21:34:45 Re: HOT chain validation in verify_heapam()