diff --git a/src/backend/access/nbtree/README b/src/backend/access/nbtree/README
index 6db203e75c..246e7a9f02 100644
--- a/src/backend/access/nbtree/README
+++ b/src/backend/access/nbtree/README
@@ -567,21 +567,15 @@ HeapTupleSatisfiesUpdate(), HeapTupleSatisfiesSelf(),
 HeapTupleSatisfiesDirty() and HeapTupleSatisfiesVacuum() are only
 ever used during write transactions, which cannot exist on the standby.
 MVCC scans are already protected by definition, so HeapTupleSatisfiesMVCC()
-is not a problem.  That leaves concern only for HeapTupleSatisfiesToast().
+is not a problem.  The optimizer looks at the boundaries of value ranges
+using HeapTupleSatisfiesNonVacuumable() with an index-only scan, which is
+also safe.  That leaves concern only for HeapTupleSatisfiesToast().
+
 HeapTupleSatisfiesToast() doesn't use MVCC semantics, though that's
 because it doesn't need to - if the main heap row is visible then the
 toast rows will also be visible. So as long as we follow a toast
 pointer from a visible (live) tuple the corresponding toast rows
 will also be visible, so we do not need to recheck MVCC on them.
-There is one minor exception, which is that the optimizer sometimes
-looks at the boundaries of value ranges using SnapshotDirty, which
-could result in returning a newer value for query statistics; this
-would affect the query plan in rare cases, but not the correctness.
-The risk window is small since the stats look at the min and max values
-in the index, so the scan retrieves a tid then immediately uses it
-to look in the heap. It is unlikely that the tid could have been
-deleted, vacuumed and re-inserted in the time taken to look in the heap
-via direct tid access. So we ignore that scan type as a problem.
 
 Other Things That Are Handy to Know
 -----------------------------------