Re: Hash Indexes
Robert Haas <robertmhaas@gmail.com>
From: Robert Haas <robertmhaas@gmail.com>
To: Amit Kapila <amit.kapila16@gmail.com>
Cc: Jesper Pedersen <jesper.pedersen@redhat.com>,
Jeff Janes <jeff.janes@gmail.com>, Mithun Cy <mithun.cy@enterprisedb.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2016-11-09T17:11:57Z
Lists: pgsql-hackers
On Wed, Nov 9, 2016 at 11:41 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: > On Wed, Nov 9, 2016 at 9:10 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> On Wed, Nov 9, 2016 at 9:04 AM, Amit Kapila <amit.kapila16@gmail.com> wrote: >> I think we can give a brief explanation right in the code comment. I >> referred to "decreasing the TIDs"; you are referring to "moving tuples >> around". But I think that moving the tuples to different locations is >> not the problem. I think the problem is that a tuple might be >> assigned a lower spot in the item pointer array > > I think we both understand the problem and it is just matter of using > different words. I will go with your suggestion and will try to > slightly adjust the README as well so that both places use same > terminology. Yes, I think we're on the same page. > Right, but we don't need that guarantee (there is no pending scan that > has seen the flag after it is cleared) to clear the flags. It was > written in one of the previous patches where I was exploring the idea > of using cleanup lock to clear the flags and then don't use the same > during vacuum. However, there were some problems in that design and I > have changed the code, but forgot to update the comment. OK, got it, thanks. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
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