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

Robert Haas <robertmhaas@gmail.com>

From: Robert Haas <robertmhaas@gmail.com>

To: Tom Lane <tgl@sss.pgh.pa.us>

Cc: Andres Freund <andres@anarazel.de>, 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-21T23:34:24Z

Lists: pgsql-hackers

On Mon, Nov 21, 2022 at 6:17 PM Tom Lane <tgl@sss.pgh.pa.us> wrote:
> evidence that it's a live problem.  API warts are really hard to
> get rid of once instituted.

Yeah, agreed.

-- 
Robert Haas
EDB: http://www.enterprisedb.com

Commits

YA attempt at taming worst-case behavior of get_actual_variable_range.
- b96a096dbc2b 11.19 landed
- ec10b6139c6d 12.14 landed
- bd06fe4dee63 14.7 landed
- 6e639267a534 13.10 landed
- 2debceed2947 15.2 landed
- 9c6ad5eaa957 16.0 landed
Improve performance of get_actual_variable_range with recently-dead tuples.
- 3ca930fc39cc 11.0 cited
Use SnapshotDirty rather than an active snapshot to probe index endpoints.
- fccebe421d0c 9.4.0 cited