On Wed, Apr 30, 2014 at 12:16 PM, Greg Stark <stark@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.