On Mon, Sep 19, 2011 at 1:53 PM, Claudio Freire <klaussfre...@gmail.com> wrote: > On Mon, Sep 19, 2011 at 3:43 PM, Merlin Moncure <mmonc...@gmail.com> wrote: >> To make the test into i/o bound, I change the setrandom from 100000 to >> 10000000; this produced some unexpected results. The hash index is >> pulling about double the tps (~80 vs ~ 40) over the hybrid version. >> Well, unless my methodology is wrong, it's unfair to claim btree is >> beating hash in 'all cases'. hm. > > Is this only selects? > Hash performs badly with updates, IIRC. > I haven't tried in a long while, though.
just selects. update test is also very interesting -- the only test I did for for updates is 'update foo set x=x+1' which was a win for btree (20-30% faster typically). perhaps this isn't algorithm induced though -- lack of wal logging could actually hurt time to commit because it deserializes i/o. merlin -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance
