From: | Erik Wienhold <ewie(at)ewie(dot)name> |
---|---|
To: | sud <suds1434(at)gmail(dot)com> |
Cc: | xof(at)thebuild(dot)com, pgsql-general <pgsql-general(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Question on indexes |
Date: | 2024-10-10 20:36:47 |
Message-ID: | aab7370a-4767-496f-9492-8fc2e10a72d1@ewie.name |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
On 2024-10-10 21:44 +0200, sud wrote:
> Not yet confirmed, but actually somehow we see the DB crashed repetitively
> a few times and teammates suspecting the cause while it tried extending
> this hash index.
Your first mail says that you're using version 15.4. You should
consider upgrading to 15.8 to get the latest bugfixes.
> Did you experience any such thing with hash index?
No. But I can't remember ever seeing a hash index in the databases that
I've worked on.
> However, as you mentioned ,if we have any column with large string/text
> values and we want it to be indexed then there is no choice but to go for a
> hash index. Please correct me if I'm wrong.
Define "large".
What kind of text (natural, JSON, XML, base64, DNA sequences, etc.) is
stored in those columns? Why do you want/need to index those columns?
Because hash indexes only support the equal operator, one can only use
that index to search for exact matches (i.e. values with identical hash
code) which I find strange for values that are so large that btree
cannot be used. But maybe you have solid use case for that.
If it's natural text and you're using tsvector for full-text search,
then GiST or GIN indexes are a better choice:
https://www.postgresql.org/docs/current/textsearch-indexes.html
--
Erik
From | Date | Subject | |
---|---|---|---|
Next Message | Efrain J. Berdecia | 2024-10-11 01:17:54 | Re: Question on indexes |
Previous Message | sud | 2024-10-10 19:44:28 | Re: Question on indexes |