From: | Robert Haas <robertmhaas(at)gmail(dot)com> |
---|---|
To: | Dilip Kumar <dilipbalaut(at)gmail(dot)com> |
Cc: | 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:22:48 |
Message-ID: | CA+TgmoY9HvvtZ63nQv6C7WWNi7YOq14gt67M=Tu9=A46anE_kw@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Tue, Aug 10, 2021 at 8:44 AM Dilip Kumar <dilipbalaut(at)gmail(dot)com> wrote:
> I was looking into the hash_multicoul.v3.patch, I have a question
>
> <para>
> - Hash indexes support only single-column indexes and do not allow
> - uniqueness checking.
> + Hash indexes support uniqueness checking.
> + Hash indexes support multi-column indexes, but only store the hash value
> + for the first column, so multiple columns are useful only for uniquness
> + checking.
> </para>
>
> The above comments say that we store hash value only for the first
> column, my question is why don't we store for other columns as well?
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. It
seems like it would be easy to do and make the behavior of the feature
way less surprising.
--
Robert Haas
EDB: http://www.enterprisedb.com
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2021-08-11 14:30:04 | Re: Next Steps with Hash Indexes |
Previous Message | Mark Dilger | 2021-08-11 14:15:38 | Re: Added schema level support for publication. |