1 Reply Latest reply: Sep 21, 2012 5:16 AM by Ashok_Ora RSS

    hash in 4.1.6

    960689
      Hash is particularly useful for people who have a huge data set and a very small amount of available memory cache.
      In this particular scenario, a B-Tree might require multiple I/Os in order to fetch the internal index pages (that don't fit in cache) and then fetch the record.
      Hash can typically access the data record with a single I/O.

      In mobile devices hashing can give better result then B-tree then why is it not present in 4.1.6.
      can I have some technical answer..?
        • 1. Re: hash in 4.1.6
          Ashok_Ora
          A b-tree index supports ordered and range queries as well as exact match queries. This is a huge benefit of b-trees. For example, if you're looking for a list of names and phone numbers sorted by last name (a very common "cellphone" query), a btree index can support that very efficiently; a hash index would not be very useful. If you're looking up a specific record, then hash index or b-tree index would work equally well.

          B-tree index is a very efficient data structure in terms of IO. Depending on the index node size and key size etc., a b-tree node can contain several hundred entries, resulting in a very high fanout. Typically, a three level index can support millions of records. Also, the internal nodes of the tree will be cached in memory - consequently, you don't incur too many IOs when accessing via b-trees.

          Your general observation about hash indexing needing less memory than b-trees is correct; however, in practice, the difference is usually not noticeable; further, the b-tree is a much more general indexing mechanism and those benefits usually outweigh IO considerations.

          There's a wealth of literature on comparisons of b-trees vs hash indexing, if you're interested in exploring this in more detail.

          Hope this helps.

          Thanks and warm regards.
          ashok