database/postgres
1
0
Fork 0
mirror of https://github.com/postgres/postgres.git synced 2025-12-10 14:22:35 +03:00
Code Activity

Doc: fix typo in hash index documentation

Browse Source 
Plus a similar fix to the README.

Backpatch as far back as the sgml issue exists.  The README issue does
exist in v14, but that seems unlikely to harm anyone.

Author: David Geier <geidav.pg@gmail.com>
Discussion: https://postgr.es/m/ed3db7ea-55b4-4809-86af-81ad3bb2c7d3@gmail.com
Backpatch-through: 15
This commit is contained in:
David Rowley
2025-12-09 14:41:30 +13:00
parent 4a8e6f43a6
commit 52382feb78
2 changed files with 8 additions and 10 deletions
Download Patch File Download Diff File Expand all files Collapse all files

9
doc/src/sgml/hash.sgml
View File

@@ -125,11 +125,10 @@
Both scanning the index and inserting tuples require locating the bucket
where a given tuple ought to be located. To do this, we need the bucket
count, highmask, and lowmask from the metapage; however, it's undesirable
for performance reasons to have to have to lock and pin the metapage for
every such operation. Instead, we retain a cached copy of the metapage
in each backend's relcache entry. This will produce the correct bucket
mapping as long as the target bucket hasn't been split since the last
cache refresh.
for performance reasons to have to lock and pin the metapage for every such
operation. Instead, we retain a cached copy of the metapage in each
backend's relcache entry. This will produce the correct bucket mapping as
long as the target bucket hasn't been split since the last cache refresh.
</para>
<para>

9
src/backend/access/hash/README
View File

@@ -171,11 +171,10 @@ Metapage Caching
Both scanning the index and inserting tuples require locating the bucket
where a given tuple ought to be located. To do this, we need the bucket
count, highmask, and lowmask from the metapage; however, it's undesirable
for performance reasons to have to have to lock and pin the metapage for
every such operation. Instead, we retain a cached copy of the metapage
in each backend's relcache entry. This will produce the correct
bucket mapping as long as the target bucket hasn't been split since the
last cache refresh.
for performance reasons to have to lock and pin the metapage for every such
operation. Instead, we retain a cached copy of the metapage in each backend's
relcache entry. This will produce the correct bucket mapping as long as the
target bucket hasn't been split since the last cache refresh.
To guard against the possibility that such a split has occurred, the
primary page of each bucket chain stores the number of buckets that