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

Justin Pryzby <pryzby@telsasoft.com>

From: Justin Pryzby <pryzby@telsasoft.com>

To: Jakub Wartak <jakub.wartak@enterprisedb.com>

Cc: Robert Haas <robertmhaas@gmail.com>, Tom Lane <tgl@sss.pgh.pa.us>, Simon Riggs <simon.riggs@enterprisedb.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, pgsql-hackers@postgresql.org

Date: 2022-11-21T17:34:31Z

Lists: pgsql-hackers

This patch version runs "continue" unconditionally (rather than
conditionally, like the previous version).

                        if (!index_fetch_heap(index_scan, tableslot))
                                continue;               /* no visible tuple, try next index entry */

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