GiST README typos
Hi Hackers,
Here are fixes to a few typos I found in the GiST README.
Yours,
--
Paul ~{:-)
pj@illuminatedcomputing.com
Attachments:
v1-0001-Fix-a-few-typos-in-the-GiST-README.patchapplication/octet-stream; name=v1-0001-Fix-a-few-typos-in-the-GiST-README.patchDownload
From 9d7e8dc4cfd7f9962588c819e1bd3f2ea707fb9e Mon Sep 17 00:00:00 2001
From: "Paul A. Jungwirth" <pj@illuminatedcomputing.com>
Date: Tue, 4 Nov 2025 21:32:35 -0800
Subject: [PATCH v1] Fix a few typos in the GiST README.
---
src/backend/access/gist/README | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/src/backend/access/gist/README b/src/backend/access/gist/README
index 8015ff19f05..6f026d22a46 100644
--- a/src/backend/access/gist/README
+++ b/src/backend/access/gist/README
@@ -172,7 +172,7 @@ it splits the page, and constructs the new downlink tuples for the split
pages. The caller must then call gistplacetopage() on the parent page to
insert the downlink tuples. The parent page that holds the downlink to
the child might have migrated as a result of concurrent splits of the
-parent, gistFindCorrectParent() is used to find the parent page.
+parent, so gistFindCorrectParent() is used to find the parent page.
Splitting the root page works slightly differently. At root split,
gistplacetopage() allocates the new child pages and replaces the old root
@@ -291,7 +291,7 @@ Buffering build algorithm
-------------------------
In the buffering index build algorithm, some or all internal nodes have a
-buffer attached to them. When a tuple is inserted at the top, the descend down
+buffer attached to them. When a tuple is inserted at the top, the descent down
the tree is stopped as soon as a buffer is reached, and the tuple is pushed to
the buffer. When a buffer gets too full, all the tuples in it are flushed to
the lower level, where they again hit lower level buffers or leaf pages. This
@@ -455,7 +455,7 @@ be reused. In order to delete an empty page, its downlink must be removed from
the parent. We scan all the internal pages, whose block numbers we memorized
in the first stage, and look for downlinks to pages that we have memorized as
being empty. Whenever we find one, we acquire a lock on the parent and child
-page, re-check that the child page is still empty. Then, we remove the
+page, then re-check that the child page is still empty. Then, we remove the
downlink and mark the child as deleted, and release the locks.
The insertion algorithm would get confused, if an internal page was completely
--
2.45.0
On Wed, Nov 5, 2025 at 1:19 PM Paul A Jungwirth
<pj@illuminatedcomputing.com> wrote:
Here are fixes to a few typos I found in the GiST README.
the child might have migrated as a result of concurrent splits of the
-parent, gistFindCorrectParent() is used to find the parent page.
+parent, so gistFindCorrectParent() is used to find the parent page.-buffer attached to them. When a tuple is inserted at the top, the descend down
+buffer attached to them. When a tuple is inserted at the top, the descent downLGTM
being empty. Whenever we find one, we acquire a lock on the parent and child
-page, re-check that the child page is still empty. Then, we remove the
+page, then re-check that the child page is still empty. Then, we remove the
downlink and mark the child as deleted, and release the locks.I still find this a bit awkward -- perhaps "and re-check"? The last
sentence could do with just the last "and" as well, I think, but
that's a style consideration and not a grammar fix.
--
John Naylor
Amazon Web Services
On Wed, Nov 5, 2025 at 7:00 PM John Naylor <johncnaylorls@gmail.com> wrote:
being empty. Whenever we find one, we acquire a lock on the parent and child -page, re-check that the child page is still empty. Then, we remove the +page, then re-check that the child page is still empty. Then, we remove the downlink and mark the child as deleted, and release the locks.I still find this a bit awkward -- perhaps "and re-check"? The last
sentence could do with just the last "and" as well, I think, but
that's a style consideration and not a grammar fix.
I nearly wrote it that way myself. It's nice that it avoids the double
"then". So I agree, let's go with "and re-check".
Thanks for the review!
Yours,
--
Paul ~{:-)
pj@illuminatedcomputing.com
On Thu, Nov 6, 2025 at 1:36 PM Paul A Jungwirth
<pj@illuminatedcomputing.com> wrote:
On Wed, Nov 5, 2025 at 7:00 PM John Naylor <johncnaylorls@gmail.com> wrote:
being empty. Whenever we find one, we acquire a lock on the parent and child -page, re-check that the child page is still empty. Then, we remove the +page, then re-check that the child page is still empty. Then, we remove the downlink and mark the child as deleted, and release the locks.I still find this a bit awkward -- perhaps "and re-check"? The last
sentence could do with just the last "and" as well, I think, but
that's a style consideration and not a grammar fix.I nearly wrote it that way myself. It's nice that it avoids the double
"then". So I agree, let's go with "and re-check".
Pushed that way, thanks!
--
John Naylor
Amazon Web Services