Re: GSoC on WAL-logging hash indexes - Mailing list pgsql-hackers

From Heikki Linnakangas
Subject Re: GSoC on WAL-logging hash indexes
Date
Msg-id 5319D0B0.7030908@vmware.com
Whole thread Raw
In response to Re: GSoC on WAL-logging hash indexes  (Robert Haas <robertmhaas@gmail.com>)
List pgsql-hackers
On 03/07/2014 03:48 PM, Robert Haas wrote:
>> >So, there seems to be a few fairly simple and independent improvements to be
>> >made:
>> >
>> >1. Replace the heavy-weight lock with pin & vacuum-lock.
>> >2. Make it crash-safe, by adding WAL-logging
>> >3. Only acquire the exclusive-lock (vacuum-lock after step 1) in VACUUM for
>> >the squeeze phase.
>> >4. Cache the metapage.
>> >
>> >We still don't know if it's going to be any better than B-tree after all
>> >that's done, but the only way to find out is to go ahead and implement it.
> I'm of the opinion that we ought to start by making splits and
> vacuuming more concurrent, and then do that stuff.

Priorities are a matter of opinion, but note that for many applications 
the concurrency of splits and vacuuming is pretty much irrelevant (at 
least after we do bullet point 3 above). Like, if the index is mostly 
read-only, or at least doesn't grow much. You'd still want it to be 
crash-safe (2), and you might care a lot about the performance of scans 
(1 and 4), but if splits and vacuum hold an exclusive lock for a few 
seconds, that's OK if you only need to do it once in a blue moon.

- Heikki



pgsql-hackers by date:

Previous
From: Robert Haas
Date:
Subject: Re: GSoC on WAL-logging hash indexes
Next
From: "ktm@rice.edu"
Date:
Subject: Re: GSoC on WAL-logging hash indexes