Re: Hash Indexes
Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
From: Mark Kirkwood <mark.kirkwood@catalyst.net.nz>
To: Amit Kapila <amit.kapila16@gmail.com>, Greg Stark <stark@mit.edu>
Cc: Tom Lane <tgl@sss.pgh.pa.us>, Andres Freund <andres@anarazel.de>,
Oskari Saarenmaa <os@ohmu.fi>, Robert Haas <robertmhaas@gmail.com>,
Bruce Momjian <bruce@momjian.us>, Jeff Janes <jeff.janes@gmail.com>,
pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2016-09-25T06:09:35Z
Lists: pgsql-hackers
On 25/09/16 18:18, Amit Kapila wrote: > On Sat, Sep 24, 2016 at 10:49 PM, Greg Stark <stark@mit.edu> wrote: >> On Thu, Sep 22, 2016 at 3:23 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote: >>> But to kick the hash AM as such to the curb is to say >>> "sorry, there will never be O(1) index lookups in Postgres". >> Well there's plenty of halfway solutions for that. We could move hash >> indexes to contrib or even have them in core as experimental_hash or >> unlogged_hash until the day they achieve their potential. >> >> We definitely shouldn't discourage people from working on hash indexes >> > Okay, but to me it appears that naming it as experimental_hash or > moving it to contrib could discourage people or at the very least > people will be less motivated. Thinking on those lines a year or so > back would have been a wise direction, but now when already there is > lot of work done (patches to make it wal-enabled, more concurrent and > performant, page inspect module are available) for hash indexes and > still more is in progress, that sounds like a step backward then step > forward. > +1 I think so too - I've seen many email threads over the years on this list that essentially state "we need hash indexes wal logged to make progress with them"...and Amit et al has/have done this (more than this obviously - made 'em better too) and I'm astonished that folk are suggesting anything other than 'commit this great patch now!'... regards Mark
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