| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Oskari Saarenmaa <os(at)ohmu(dot)fi> |
| Cc: | Robert Haas <robertmhaas(at)gmail(dot)com>, Bruce Momjian <bruce(at)momjian(dot)us>, Jeff Janes <jeff(dot)janes(at)gmail(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Hash Indexes |
| Date: | 2016-09-21 22:29:54 |
| Message-ID: | 20160921222954.kgvndc647mue6tzm@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On 2016-09-21 19:49:15 +0300, Oskari Saarenmaa wrote:
> 21.09.2016, 15:29, Robert Haas kirjoitti:
> > For PostgreSQL, I expect the benefits of improving hash indexes to be
> > (1) slightly better raw performance for equality comparisons and (2)
> > better concurrency.
>
> There's a third benefit: with large columns a hash index is a lot smaller on
> disk than a btree index. This is the biggest reason I've seen people want
> to use hash indexes instead of btrees. hashtext() btrees are a workaround,
> but they require all queries to be adjusted which is a pain.
Sure. But that can be addressed, with a lot less effort than fixing and
maintaining the hash indexes, by adding the ability to do that
transparently using btree indexes + a recheck internally. How that
compares efficiency-wise is unclear as of now. But I do think it's
something we should measure before committing the new code.
Andres
| From | Date | Subject | |
|---|---|---|---|
| Next Message | AP | 2016-09-21 23:47:23 | Re: Hash Indexes |
| Previous Message | Jeff Janes | 2016-09-21 22:27:31 | Re: Hash Indexes |