Re: Hash Indexes
Amit Kapila <amit.kapila16@gmail.com>
From: Amit Kapila <amit.kapila16@gmail.com>
To: Jeff Janes <jeff.janes@gmail.com>
Cc: Jesper Pedersen <jesper.pedersen@redhat.com>,
Mithun Cy <mithun.cy@enterprisedb.com>, Robert Haas <robertmhaas@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2016-09-15T06:13:07Z
Lists: pgsql-hackers
One other point, I would like to discuss is that currently, we have a concept for tracking active hash scans (hashscan.c) which I think is mainly to protect splits when the backend which is trying to split has some scan open. You can read "Other Notes" section of access/hash/README for further details. I think after this patch we don't need that mechanism for splits because we always retain a pin on bucket buffer till all the tuples are fetched or scan is finished which will defend against a split by our own backend which tries to ensure cleanup lock on bucket. However, we might need it for vacuum (hashbulkdelete), if we want to get rid of cleanup lock in vacuum, once we have a page-at-a-time scan mode implemented for hash indexes. If you agree with above analysis, then we can remove the checks for _hash_has_active_scan from both vacuum and split path and also remove corresponding code from hashbegin/end scan, but retain that hashscan.c for future improvements. I am posting this as a separate mail to avoid it getting lost as one of the points in long list of review points discussed. Thoughts? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
Commits
-
Remove _hash_wrtbuf() in favor of calling MarkBufferDirty().
- 25216c989384 10.0 landed
-
Fix race introduced by 6d46f4783efe457f74816a75173eb23ed8930020.
- 2f4193c3509a 10.0 cited
-
Improve hash index bucket split behavior.
- 6d46f4783efe 10.0 landed
-
Reduce pinning and buffer content locking for btree scans.
- 2ed5b87f96d4 9.5.0 cited