1. 5
  1.  

  2. 1

    For what workload? The article neglects to say what kind of query they are doing.

    I’d be willing to bet that full table scans are faster than both hash and btree indexes.

    (for databases with 2 or 3 elements.)

    1. 2

      What do you mean? The first paragraph covers it:

      There are multiple ways in which we can compare the performance of Hash and Btree indexes, like the time taken for creation of the index, search or insertion in the index. This blog will mainly focus on the search operation.

      He also shows the pgbench command lines that he used, so it should be possible for others to reproduce the results.

      Then the paragraph after the second graph covers it again, mentioning community feedback where hash indexing has improved performance on integer IDs and varchar fields.

      Not sure what else you could ask for.

      1. 3

        This blog will mainly focus on the search operation.

        Range queries are very different from querying for a specific key. Hash indexes help with one, and do not help with the other. If hash indexes were faster in general, that would be remarkable.

        And maybe I’m not familiar enough with pgbench, but the information in the post does not seem to indicate anything about the queries or the data.

        1. 3

          You might then want to do your homework and read a paragraph or two from the pgbench documentation before claiming that the post author didn’t do his homework?

          1. 2

            It seems reasonable to expect that performance claims where you expect tradeoffs would address this. Either by showcasing the tradeoff, or showing that the expected tradeoff has been solved.

            If the reader sees a universal statement and:

            1. Needs to needs have enough background knowledge to know that it probably isn’t universal
            2. Needs to figure out that pgbench has default tests
            3. Needs to look up the pgbench documentation to find out which queries are being made
            4. Figure out what parts of the indexing code are stressed by those queries
            5. Realize that the default pgbench tests are fairly simple, and do not seem designed to stress indexing.

            Maybe the article could use work. And if the performance boost was universal in the way that this post implied, then I’d be very interested to see far more information on how that was actually accomplished, because fast range queries with hash indexes would be amazing.

            1. 0

              I, for one, don’t want every technical article and blog post to be written for people with zero experience.

              And if the performance boost was universal in the way that this post implied, …

              TFA didn’t imply that at all.

          2. 1

            If it were an intro to databases article, I think you would have a point.

            However, the author doesn’t mention range queries at all, and it’s safe to assume that a PostgreSQL developer’s blog is targeted at people who know that range queries and searching for a single item are different.

            No point being snarky simply because somebody didn’t qualify every little thing they said and go into mundane details of easily researched tools like pgbench.