I don't think there is real disagreement on whether it makes sense to use
hash indexes or not - we're basically just discussing where to put the
feature.

Right now, there's basically one storage engine and one index type.

However, there's demand for multiple storage engines, with each their index
types, and the ability to select engine type for each database table:

- Archiving/logging: Write sequentially, compress it, no indexing. All
select statements must search the entire table.
- Temporary tables: No write-buffer flushing on commits. Very fast writes,
but no persistense on database shutdown.
- RAM-based: Keep all data in RAM at all times, only write full dumps or
changelog to disk. Extremely fast for limited data amounts, and because of
possible optimizations, data will occupy less space in RAM than they would
in the current ODS.

Each of these would use different index types.

Because Firebirds lacks these engines, application developers need to make
workarounds that are much bigger than what is needed to work around the
current limit on index size.


[Non-text portions of this message have been removed]