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: Simon Riggs <simon.riggs@enterprisedb.com>
Cc: pgsql-hackers@lists.postgresql.org, Robert Haas <robertmhaas@gmail.com>, Jakub Wartak <jakub.wartak@enterprisedb.com>, Tom Lane <tgl@sss.pgh.pa.us>, Alvaro Herrera <alvherre@alvh.no-ip.org>, PostgreSQL Hackers <pgsql-hackers@postgresql.org>
Date: 2022-11-21T19:09:52Z
Lists: pgsql-hackers 
Hi, 

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. 

I don't really understand the point of limiting in the index - where would the large number of pages accessed come from?

Andres
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

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.