0001-Fix-hash-index-documentation.patch
text/x-patch
Filename: 0001-Fix-hash-index-documentation.patch
Type: text/x-patch
Part: 0
Patch
Same data as JSON:
GET /api/v1/attachments/:id/patch
the parsed metadata as JSON — format, series position, per-file stats; never the diff bytes.
API reference →
Format: format-patch
Series: patch 0001
Subject: Fix hash index documentation
| File | + | − |
|---|---|---|
| doc/src/sgml/hash.sgml | 1 | 1 |
| src/backend/access/hash/README | 1 | 1 |
From 6420ef7f24f150c88110343634758ae8fb3a779d Mon Sep 17 00:00:00 2001 From: David Geier <geidav.pg@gmail.com> Date: Mon, 8 Dec 2025 20:37:02 +0100 Subject: [PATCH] Fix hash index documentation --- doc/src/sgml/hash.sgml | 2 +- src/backend/access/hash/README | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff --git a/doc/src/sgml/hash.sgml b/doc/src/sgml/hash.sgml index 9e69ef91fe8..5bb280af71d 100644 --- a/doc/src/sgml/hash.sgml +++ b/doc/src/sgml/hash.sgml @@ -125,7 +125,7 @@ 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 + 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 diff --git a/src/backend/access/hash/README b/src/backend/access/hash/README index 13dc59c124a..8187d20452f 100644 --- a/src/backend/access/hash/README +++ b/src/backend/access/hash/README @@ -171,7 +171,7 @@ 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 +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 -- 2.51.0