Horton

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

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

View thread View on postgr.es
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Andres Freund <andres@anarazel.de>
Cc: Simon Riggs <simon.riggs@enterprisedb.com>, pgsql-hackers@lists.postgresql.org, Robert Haas <robertmhaas@gmail.com>, Jakub Wartak <jakub.wartak@enterprisedb.com>, Alvaro Herrera <alvherre@alvh.no-ip.org>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2022-11-21T19:15:18Z
Lists: pgsql-hackers 
Andres Freund <andres@anarazel.de> writes:
> On November 21, 2022 10:44:17 AM PST, Simon Riggs <simon.riggs@enterprisedb.com> wrote:
>> Robert, something like this perhaps? limit on both the index and the heap.

> I don't think we should add additional code / struct members into very common good paths for these limits. 

Yeah, I don't like that either: for one thing, it seems completely
unsafe to back-patch.

			regards, tom lane

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.