| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Amit Kapila <amit(dot)kapila16(at)gmail(dot)com> |
| Cc: | pgsql-hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Hash Indexes |
| Date: | 2016-09-15 14:23:09 |
| Message-ID: | 20160915142309.yisxr6vcdavilt2s@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2016-05-10 17:39:22 +0530, Amit Kapila wrote:
> For making hash indexes usable in production systems, we need to improve
> its concurrency and make them crash-safe by WAL logging them.
One earlier question about this is whether that is actually a worthwhile
goal. Are the speed and space benefits big enough in the general case?
Could those benefits not be achieved in a more maintainable manner by
adding a layer that uses a btree over hash(columns), and adds
appropriate rechecks after heap scans?
Note that I'm not saying that hash indexes are not worthwhile, I'm just
doubtful that question has been explored sufficiently.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Pavan Deolasee | 2016-09-15 14:25:42 | Re: Printing bitmap objects in the debugger |
| Previous Message | Alvaro Herrera | 2016-09-15 14:19:27 | Re: select_parallel test fails with nonstandard block size |