| From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
|---|---|
| To: | Robert Haas <robertmhaas(at)gmail(dot)com> |
| Cc: | Dilip Kumar <dilipbalaut(at)gmail(dot)com>, Simon Riggs <simon(dot)riggs(at)enterprisedb(dot)com>, Amit Kapila <amit(dot)kapila16(at)gmail(dot)com>, PostgreSQL Developers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
| Subject: | Re: Next Steps with Hash Indexes |
| Date: | 2021-08-11 14:30:04 |
| Message-ID: | 3970993.1628692204@sss.pgh.pa.us |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Robert Haas <robertmhaas(at)gmail(dot)com> writes:
> I suspect it would be hard to store multiple hash values, one per
> column. It seems to me that what we ought to do is combine the hash
> values for the individual columns using hash_combine(64) and store the
> combined value. I can't really imagine why we would NOT do that.
That would make it impossible to use the index except with queries
that provide equality conditions on all the index columns. Maybe
that's fine, but it seems less flexible than other possible definitions.
It really makes me wonder why anyone would bother with a multicol
hash index.
regards, tom lane
| From | Date | Subject | |
|---|---|---|---|
| Next Message | David G. Johnston | 2021-08-11 14:41:04 | Re: DROP relation IF EXISTS Docs and Tests - Bug Fix |
| Previous Message | Robert Haas | 2021-08-11 14:22:48 | Re: Next Steps with Hash Indexes |