title: Why postgresql "disrespects" hash indices?
body: <p>I know postgresql discourages using hash indices. They actually say:</p>
  
  <blockquote>
    <p>"Caution Hash index operations are not presently WAL-logged,  so hash
    indexes might need to be rebuilt with REINDEX after a database crash. 
    They are also not replicated over streaming or file-based replication.
    For these reasons, hash index use is presently discouraged."</p>
  </blockquote>
  
  <p>This is the good argument not to use them at all, but I can't understand why postgresql developers don't do effort to make hash indices first class citizens  and to encourage their usage in certain situations rather than discourage to do it at all.</p>
  
  <p>Actually if you only need to search for equality, hash indices should be far superior than any kind of trees, since they do search, insertion and deletion in o(1), and balanced trees naturally can't be better than o(log(n)). In worst case hash indices could work for o(n), but there is a bunch of known techniques to avoid worst case. If I were a db engine architect, such an argument should definitely rule my decision to make hash indices a viable alternative, but with postgresql it seems different. Is there a technical reason for this, or such decision is not technically motivated?</p>