Remove obsolete nbtree README commentary.
authorPeter Geoghegan <pg@bowt.ie>
Wed, 14 Aug 2019 00:16:44 +0000 (17:16 -0700)
committerPeter Geoghegan <pg@bowt.ie>
Wed, 14 Aug 2019 00:16:44 +0000 (17:16 -0700)
Commit d2086b08b02 removed almost all cases where nbtree must release a
read buffer lock and acquire a write buffer lock instead, so remaining
cases in which that's still necessary are not notable enough to appear
in the nbtree README.

More importantly, holding on to a buffer pin in cases where nbtree must
trade a read lock for a write lock is very unlikely to save any I/O.
This seems to have been a long overlooked throwback to a time when
nbtree cared about write-ordering dependencies, and performed
synchronous buffer writes.  It hasn't worked that way in many years.

src/backend/access/nbtree/README

index 3d01b7854df2b7a904c647423b64c07a5c189de9..dce8bc98e93b95aab9b4eb488ffb720bbdf501ec 100644 (file)
@@ -65,10 +65,7 @@ copies of tree pages are unshared.  Postgres shares in-memory buffers
 among backends.  As a result, we do page-level read locking on btree
 pages in order to guarantee that no record is modified while we are
 examining it.  This reduces concurrency but guarantees correct
-behavior.  An advantage is that when trading in a read lock for a
-write lock, we need not re-read the page after getting the write lock.
-Since we're also holding a pin on the shared buffer containing the
-page, we know that buffer still contains the page and is up-to-date.
+behavior.
 
 We support the notion of an ordered "scan" of an index as well as
 insertions, deletions, and simple lookups.  A scan in the forward