Re: Next Steps with Hash Indexes

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

In response to

Responses

Browse pgsql-hackers by date

  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.