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 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 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 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 for performance reasons to have to lock and pin the metapage for every such
every such operation. Instead, we retain a cached copy of the metapage operation. Instead, we retain a cached copy of the metapage in each
in each backend's relcache entry. This will produce the correct bucket backend's relcache entry. This will produce the correct bucket mapping as
mapping as long as the target bucket hasn't been split since the last long as the target bucket hasn't been split since the last cache refresh.
cache refresh.
</para> </para>
<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 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 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 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 for performance reasons to have to lock and pin the metapage for every such
every such operation. Instead, we retain a cached copy of the metapage operation. Instead, we retain a cached copy of the metapage in each backend's
in each backend's relcache entry. This will produce the correct relcache entry. This will produce the correct bucket mapping as long as the
bucket mapping as long as the target bucket hasn't been split since the target bucket hasn't been split since the last cache refresh.
last cache refresh.
To guard against the possibility that such a split has occurred, the To guard against the possibility that such a split has occurred, the
primary page of each bucket chain stores the number of buckets that primary page of each bucket chain stores the number of buckets that