nbtree: tighten up array recheck rules.

Be more conservative when performing a scheduled recheck of an nbtree
scan's array keys once on the next page, having set so->scanBehind: back
out of reading the page (perform another primitive scan instead) when
the next page's high key/finaltup has an untruncated prefix of matching
values and truncated suffix attributes associated with lower-order keys.
In other words, stop assuming that the lower-order keys have been
satisfied by the truncated suffix attributes in this context (only do so
when considering scheduling a recheck within _bt_advance_array_keys).

The new behavior is more logical: if the next page read after setting
so->scanBehind can only contain tuples that are themselves "behind the
scan", that's reason enough to cut our losses.  In general, when we set
so->scanBehind, we only expect to perform one recheck on the next page
to make a final decision about whether or not to continue the current
primitive index scan.  It seems unprincipled for the recheck to allow a
_bt_readpage to continue unless the scan's arrays will advance/unless
the page might actually contain relevant tuples.

In practice it is highly unlikely that things will line up like this
(the untruncated prefix of attribute values from the next page's high
key is seldom an exact match for their corresponding array's current
element following array advancement on the original/previous page).
That gives us all the more reason to keep things simple and consistent.

This was arguably an oversight in commit 9a2e2a285a, which improved
nbtree array primitive scan scheduling.

Author: Peter Geoghegan <pg@bowt.ie>
Discussion: https://postgr.es/m/CAH2-WzkXzJajgyW-pCQ7vaDPhaT3huU+Zw_j448rpCBEsu2YOQ@mail.gmail.com

diff --git a/src/backend/access/nbtree/nbtutils.c b/src/backend/access/nbtree/nbtutils.c
index adfa2fd292f7fd9e4986268d0b59ef402c594050..c580c2bf527e3ded057015c76bb71138320d8e6e 100644 (file)
--- a/src/backend/access/nbtree/nbtutils.c
+++ b/src/backend/access/nbtree/nbtutils.c
@@ -2393,11 +2393,27 @@ _bt_scanbehind_checkkeys(IndexScanDesc scan, ScanDirection dir,
    TupleDesc   tupdesc = RelationGetDescr(rel);
    BTScanOpaque so = (BTScanOpaque) scan->opaque;
    int         nfinaltupatts = BTreeTupleGetNAtts(finaltup, rel);
+   bool        scanBehind;
 
    Assert(so->numArrayKeys);
 
    if (_bt_tuple_before_array_skeys(scan, dir, finaltup, tupdesc,
-                                    nfinaltupatts, false, 0, NULL))
+                                    nfinaltupatts, false, 0, &scanBehind))
+       return false;
+
+   /*
+    * If scanBehind was set, all of the untruncated attribute values from
+    * finaltup that correspond to an array match the array's current element,
+    * but there are other keys associated with truncated suffix attributes.
+    * Array advancement must have incremented the scan's arrays on the
+    * previous page, resulting in a set of array keys that happen to be an
+    * exact match for the current page high key's untruncated prefix values.
+    *
+    * This page definitely doesn't contain tuples that the scan will need to
+    * return.  The next page may or may not contain relevant tuples.  Handle
+    * this by cutting our losses and starting a new primscan.
+    */
+   if (scanBehind)
        return false;
 
    if (!so->oppositeDirCheck)