Horton

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

Andres Freund <andres@anarazel.de>

View thread View on postgr.es
From: Andres Freund <andres@anarazel.de>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon.riggs@enterprisedb.com>, pgsql-hackers@lists.postgresql.org, Jakub Wartak <jakub.wartak@enterprisedb.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2022-11-21T21:53:52Z
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

Commits

  1. YA attempt at taming worst-case behavior of get_actual_variable_range.

  2. Improve performance of get_actual_variable_range with recently-dead tuples.

  3. Use SnapshotDirty rather than an active snapshot to probe index endpoints.