On Wed, Apr 30, 2014 at 12:16 PM, Greg Stark <st...@mit.edu> wrote: > I think the key question was if someone wanted to develop a good hash > index would they start from our current hash index or would they be > better off starting from a fresh codebase?
If it were me I'd start with the current code. It would be nice if one could just fork the code to have a new type of index (say "hash2") which is initially identical, but I never figured out how to do that. > If the former then we > should add WAL logging and throw GSOC and other people who ask for > projects at it. If the latter then we should throw out the current > codebase and let people develop extensions that add new hash index > code until someone comes up with a good design we want to move to > core. > Extensions have no hooks into the WAL system, and I'm not optimistic that that will ever change. Relegating a fundamentally new index to be an extension virtually *guarantees* that it will never be WAL logged. > > Incidentally something else I've considered would be having a WAL > record type saying "relation corrupted" and emitting one the first > time a hash index is touched after a checkpoint. That could provide a > general mechanism that might be useful for unlogged operations (and > might be combinable with the infrastructure for unlogged tables). But > it seems like a better tool for other objects than hash indexes. > +1. I often lament that unlogged tables cannot be used on a standby or a test server which were derived from a hot backup. In the case of unlogged tables, this does mean we would need a way to checkpoint them with a non-shutdown checkpoint, though. I don't know if that would need a different type of unlogged table, or a different type of checkpoint. Cheers, Jeff
