Re: Hash Indexes
Tom Lane <tgl@sss.pgh.pa.us>
From: Tom Lane <tgl@sss.pgh.pa.us>
To: Peter Geoghegan <pg@heroku.com>
Cc: Robert Haas <robertmhaas@gmail.com>,
Amit Kapila <amit.kapila16@gmail.com>,
Andres Freund <andres@anarazel.de>, Jeff Janes <jeff.janes@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>,
Jesper Pedersen <jesper.pedersen@redhat.com>,
Mithun Cy <mithun.cy@enterprisedb.com>
Date: 2016-09-30T17:01:39Z
Lists: pgsql-hackers
Peter Geoghegan <pg@heroku.com> writes: > On Fri, Sep 30, 2016 at 4:46 PM, Robert Haas <robertmhaas@gmail.com> wrote: >> The fact that we have hash indexes already and cannot remove them >> because too much other code depends on hash opclasses is also, in my >> opinion, a sufficiently good reason to pursue improving them. > I think that Andres was suggesting that hash index opclasses would be > usable with hash-over-btree, so you might still not end up with the > wart of having hash opclasses without hash indexes (an idea that has > been proposed and rejected at least once before now). Andres? That's an interesting point. If we were to flat-out replace the hash AM with a hash-over-btree AM, the existing hash opclasses would just migrate to that unchanged. But if someone wanted to add hash-over-btree alongside the hash AM, it would be necessary to clone all those opclass entries, or else find a way for the two AMs to share pg_opclass etc entries. Either one of those is kind of annoying. (Although if we did do the work of implementing the latter, it might come in handy in future; you could certainly imagine that there will be cases like a next-generation GIST AM wanting to reuse the opclasses of existing GIST, say.) But having said that, I remain opposed to removing the hash AM. If someone wants to implement hash-over-btree, that's cool with me, but I'd much rather put it in beside plain hash and let them duke it out in the field. regards, tom lane
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