From: Peter Geoghegan Date: Wed, 14 Aug 2019 00:16:44 +0000 (-0700) Subject: Remove obsolete nbtree README commentary. X-Git-Tag: REL_13_BETA1~1632 X-Git-Url: http://git.ipfire.org/?a=commitdiff_plain;h=68ef887842ff716097bbb1bad86a40bb62247061;p=thirdparty%2Fpostgresql.git Remove obsolete nbtree README commentary. 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. --- diff --git a/src/backend/access/nbtree/README b/src/backend/access/nbtree/README index 3d01b7854df..dce8bc98e93 100644 --- a/src/backend/access/nbtree/README +++ b/src/backend/access/nbtree/README @@ -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