| From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
|---|---|
| To: | Jesper Pedersen <jesper(dot)pedersen(at)redhat(dot)com> |
| Cc: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Tomasz Ostrowski <tometzky+pg(at)ato(dot)waw(dot)pl>, "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: Multicolumn hash indexes |
| Date: | 2017-09-27 15:34:22 |
| Message-ID: | CA+TgmoZzMEN3Q0E6Ryn7scR9rtb==ejeRPVExtD776ithp++hw@mail.gmail.com |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
On Wed, Sep 27, 2017 at 9:56 AM, Jesper Pedersen
<jesper(dot)pedersen(at)redhat(dot)com> wrote:
> Maybe an initial proof-of-concept could store the hash of the first column
> (col1) plus the hash of all columns (col1, col2, col3) in the index, and see
> what requirements / design decisions would appear from that.
I thought about that sort of thing yesterday but it's not that simple.
The problem is that the hash code isn't just stored; it's used to
assign tuples to buckets. If you have two hash codes, you have to
pick one of the other to use for assigning the tuple to a bucket. And
then if you want to search using the other hash code, you have to
search all of the buckets, which will stink.
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Emre Hasegeli | 2017-09-27 15:44:52 | Re: [PATCH] Improve geometric types |
| Previous Message | Nico Williams | 2017-09-27 15:33:59 | Re: Multicolumn hash indexes |