Skip to content
GitLab
Explore
Sign in
Register
Primary navigation
Search or go to…
Project
P
postgres-lambda-diff
Manage
Activity
Members
Labels
Plan
Issues
Issue boards
Milestones
Wiki
Code
Merge requests
Repository
Branches
Commits
Tags
Repository graph
Compare revisions
Snippets
Build
Pipelines
Jobs
Pipeline schedules
Artifacts
Deploy
Releases
Container registry
Model registry
Operate
Environments
Monitor
Incidents
Analyze
Value stream analytics
Contributor analytics
CI/CD analytics
Repository analytics
Model experiments
Help
Help
Support
GitLab documentation
Compare GitLab plans
Community forum
Contribute to GitLab
Provide feedback
Keyboard shortcuts
?
Snippets
Groups
Projects
Show more breadcrumbs
Jakob Huber
postgres-lambda-diff
Commits
8b2450c8
Commit
8b2450c8
authored
21 years ago
by
Tom Lane
Browse files
Options
Downloads
Patches
Plain Diff
Fix a couple typos, add some more comments.
parent
39673ca4
Branches
Branches containing commit
Tags
Tags containing commit
No related merge requests found
Changes
1
Show whitespace changes
Inline
Side-by-side
Showing
1 changed file
src/backend/access/hash/README
+15
-4
15 additions, 4 deletions
src/backend/access/hash/README
with
15 additions
and
4 deletions
src/backend/access/hash/README
+
15
−
4
View file @
8b2450c8
$Header: /cvsroot/pgsql/src/backend/access/hash/README,v 1.
1
2003/09/0
1 20:24:49
tgl Exp $
$Header: /cvsroot/pgsql/src/backend/access/hash/README,v 1.
2
2003/09/0
2 03:29:01
tgl Exp $
This directory contains an implementation of hash indexing for Postgres.
...
...
@@ -189,7 +189,7 @@ The insertion algorithm is rather similar:
read/sharelock meta page
compute bucket number for target hash key
release meta page
share-lock bucket page (to prevent split/compact this bucket)
share-lock bucket page (to prevent split/compact
of
this bucket)
release page 0 share-lock
-- (so far same as reader)
read/exclusive-lock current page of bucket
...
...
@@ -334,7 +334,7 @@ Obtaining an overflow page:
release bitmap page
loop back to try next bitmap page, if any
-- here when we have checked all bitmap pages; we hold meta excl. lock
extend index to add another
bitmap
page; update meta information
extend index to add another
overflow
page; update meta information
write/release meta page
return page number
...
...
@@ -344,6 +344,12 @@ concurrency against processes just entering the index. We don't want
to hold the metapage exclusive lock while reading in a bitmap page.
(We can at least avoid repeated buffer pin/unpin here.)
The normal path for extending the index does not require doing I/O while
holding the metapage lock. We do have to do I/O when the extension
requires adding a new bitmap page as well as the required overflow page
... but that is an infrequent case, so the loss of concurrency seems
acceptable.
The portion of tuple insertion that calls the above subroutine looks
like this:
...
...
@@ -392,7 +398,12 @@ algorithm is:
release meta page
We have to do it this way because we must clear the bitmap bit before
changing the first-free-bit field.
changing the first-free-bit field (hashm_firstfree). It is possible that
we set first-free-bit too small (because someone has already reused the
page we just freed), but that is okay; the only cost is the next overflow
page acquirer will scan more bitmap bits than he needs to. What must be
avoided is having first-free-bit greater than the actual first free bit,
because then that free page would never be found by searchers.
All the freespace operations should be called while holding no buffer
locks. Since they need no lmgr locks, deadlock is not possible.
...
...
This diff is collapsed.
Click to expand it.
Preview
0%
Loading
Try again
or
attach a new file
.
Cancel
You are about to add
0
people
to the discussion. Proceed with caution.
Finish editing this message first!
Save comment
Cancel
Please
register
or
sign in
to comment