Re: GSoC on WAL-logging hash indexes
От | Heikki Linnakangas |
---|---|
Тема | Re: GSoC on WAL-logging hash indexes |
Дата | |
Msg-id | 5319D0B0.7030908@vmware.com обсуждение исходный текст |
Ответ на | Re: GSoC on WAL-logging hash indexes (Robert Haas <robertmhaas@gmail.com>) |
Список | 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 по дате отправления: