| From: | Merlin Moncure <mmoncure(at)gmail(dot)com> |
|---|---|
| To: | Claudio Freire <klaussfreire(at)gmail(dot)com> |
| Cc: | Robert Klemme <shortcutter(at)googlemail(dot)com>, Stefan Keller <sfkeller(at)gmail(dot)com>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Peter Geoghegan <peter(at)2ndquadrant(dot)com>, pgsql-performance(at)postgresql(dot)org |
| Subject: | Re: Hash index use presently(?) discouraged since 2005: revive or bury it? |
| Date: | 2011-09-20 16:11:28 |
| Message-ID: | CAHyXU0w3HniZ58tbNWtBL=_uxqbsuu7Qq_TqHLHF-nF7v8FfZA@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-performance |
On Mon, Sep 19, 2011 at 1:53 PM, Claudio Freire <klaussfreire(at)gmail(dot)com> wrote:
> On Mon, Sep 19, 2011 at 3:43 PM, Merlin Moncure <mmoncure(at)gmail(dot)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
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Venkat Balaji | 2011-09-20 16:22:42 | : Performance Improvement Strategy |
| Previous Message | Gunnlaugur Þór Briem | 2011-09-20 09:15:30 | Re: Constraint exclusion on UNION ALL subqueries with WHERE conditions |