MIME-Version: 1.0
References: 
 <CAH2-Wzkt1WkKp4VRJu3qHfmKXc8W+XYv1RXg5d2d3fSvAeO=rg@mail.gmail.com>
 <CAKZiRmwjmGBWvPx6=qFRXJhm=sCrUyE7pPiPGA454LDdKemtQg@mail.gmail.com>
 <CAH2-Wz=w_pQj80wi=Mf=S3V-SVbobFxqiNPSj-vFW2Hfpi4mdA@mail.gmail.com>
 <4s3vd2rjll4vgnhdnajrqwsnhnmnmtmjtwjngfsrzmjx3nrxvp@la2vohpjojnk>
 <CAH2-WzkmWviX6fGwJ_a775WMQ5-Qvg_FPXg=5wA4DMDeScmURw@mail.gmail.com>
 <CAH2-WzmugSOCGw-+mjocGRXBbwSevjMJ41dLaF0ukJzUGEKF=Q@mail.gmail.com>
In-Reply-To: 
 <CAH2-WzmugSOCGw-+mjocGRXBbwSevjMJ41dLaF0ukJzUGEKF=Q@mail.gmail.com>
From: Jakub Wartak <jakub.wartak@enterprisedb.com>
Date: Wed, 24 Jun 2026 10:48:19 +0200
Message-ID: 
 <CAKZiRmx00w5UyeTq7imXtQG++wiBNqsHdfc2KPNcsbTLdmLUtA@mail.gmail.com>
Subject: Re: Problems with get_actual_variable_range's VISITED_PAGES_LIMIT
To: Peter Geoghegan <pg@bowt.ie>
Cc: Andres Freund <andres@anarazel.de>,
	PostgreSQL Hackers <pgsql-hackers@lists.postgresql.org>,
 MARK CALLAGHAN <mdcallag@gmail.com>,
	Tomas Vondra <tomas@vondra.me>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Archived-At: 
 <https://www.postgresql.org/message-id/CAKZiRmx00w5UyeTq7imXtQG%2B%2BwiBNqsHdfc2KPNcsbTLdmLUtA%40mail.gmail.com>
Precedence: bulk

On Tue, Jun 23, 2026 at 10:06=E2=80=AFPM Peter Geoghegan <pg@bowt.ie> wrote=
:
>
> On Thu, Mar 12, 2026 at 9:13=E2=80=AFPM Peter Geoghegan <pg@bowt.ie> wrot=
e:
> > I'm trying to be practical here. I want to design a solution
> > compatible with the changes that we're making to the table AM
> > interface. That fixes Mark's complaint. Ideally, this should avoid
> > adding much new code to hot code paths. Any design that meets those
> > goals is acceptable to me.
>
> The latest version of the index prefetching patch set has a new patch for=
 this:
>
> https://postgr.es/m/CAH2-WzkZTkDuyVFszLwPJesF9pS5E8m0UA+344bx-B-zfA5kaw@m=
ail.gmail.com
>
> My original proposal involved wholly replacing VISITED_PAGES_LIMIT; my
> new approach complements it by specifically targeting its one major
> weakness. A new INDEX_PAGES_LIMIT mechanism will only tally index leaf
> page reads that return zero matching items to the table AM, and will
> only give up when that count reaches 3. VISITED_PAGES_LIMIT itself
> works as before.
>
> Importantly, this allows VISITED_PAGES_LIMIT to work exactly the same
> way on standbys as it does today. During hot standby, LP_DEAD bits
> cannot be set or used to avoid heap fetches. As long as each leaf page
> returns at least one match (which could still be a TID pointing to a
> dead heap tuple), nothing changes -- INDEX_PAGES_LIMIT does nothing
> new, we rely on VISITED_PAGES_LIMIT in the traditional way.

Hi Peter, thanks for working on this. I have noob question, in v28-0003:

--- a/src/backend/utils/adt/selfuncs.c
+++ b/src/backend/utils/adt/selfuncs.c
@@ -7185,8 +7185,17 @@ get_actual_variable_endpoint(Relation heapRel,
      * We set xs_visited_pages_limit to tell the table AM to count distinc=
t
      * heap pages visited for non-visible tuples and give up after the lim=
it
      * is exceeded.
+     *
+     * We also set xs_index_pages_limit to independently tell the index AM=
 to
+     * give up when this many leaf pages that lack even one matching index
+     * tuple have been read.  This acts as a backstop against pages entire=
ly
+     * full of index entries that were already marked killed (typically by
+     * prior calls here).  That way we avoid hopelessly searching through =
an
+     * unbounded number of index leaf pages that don't contain even a sing=
le
+     * still-live entry (which can't trigger xs_visited_pages_limit).
      */
 #define VISITED_PAGES_LIMIT 100
+#define INDEX_PAGES_LIMIT 3

So, is this based that proportion that we assume that everywhere on average
33 heap pages are going to be covered by 1 btree page? (just asking if we
I get the assumption right, I don't have anything against it).

-J.