Re: Problems with get_actual_variable_range's VISITED_PAGES_LIMIT

On Tue, Jun 23, 2026 at 10:06 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
>
> On Thu, Mar 12, 2026 at 9:13 PM Peter Geoghegan <pg(at)bowt(dot)ie> wrote:
> > 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@mail.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 distinct
* heap pages visited for non-visible tuples and give up after the limit
* 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 entirely
+ * 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 single
+ * 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.