On Fri, Oct 11, 2024 at 6:18 PM Greg Sabino Mullane
wrote:
> (please start a new thread in the future rather than replying to an
> existing one)
>
> You cannot query on b and use an index on (a,b) as you observed. However,
> you can have two indexes:
>
> index1(a)
> index2(b)
>
> Postgres will be
(please start a new thread in the future rather than replying to an
existing one)
You cannot query on b and use an index on (a,b) as you observed. However,
you can have two indexes:
index1(a)
index2(b)
Postgres will be able to combine those when needed in the case where your
WHERE clause needs t
On Fri, Oct 11, 2024 at 5:00 PM Greg Sabino Mullane
wrote:
> 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.
>>
>
> There are other strategies / solutions, but we would need
>
> 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.
>
There are other strategies / solutions, but we would need to learn more
about your use case.
Cheers,
Greg
On Fri, 2024-10-11 at 00:19 +0530, sud wrote:
> I have never used any 'hash index' but saw documents in the past suggesting
> issues
> around hash index , like WAL doesnt generate for "hash index" which means we
> can't
> get the hash index back after crash also they are not applied to replicas e
They are extremely efficient for joins!!!
Yahoo Mail: Search, Organize, Conquer
On Thu, Oct 10, 2024 at 2:52 PM, Christophe Pettus wrote:
> On Oct 10, 2024, at 11:49, sud wrote:
>
> Hi,
> I have never used any 'hash index' but saw documents in the past suggesting
> issues around hash
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.
On Fri, Oct 11, 2024 at 12:51 AM Erik Wienhold wrote:
> On 2024-10-10 20:49 +0200, sud wrote:
> > However, we are seeing that one of the databases has multiple hash
> indexes
> > created. So I wanted to understand from experts here, if it's advisable
> in
> > any specific scenarios over B-tre des
On 2024-10-10 20:49 +0200, sud wrote:
> However, we are seeing that one of the databases has multiple hash indexes
> created. So I wanted to understand from experts here, if it's advisable in
> any specific scenarios over B-tre despite such downsides?
Two things come to my mind:
1. Btree puts a l
> On Oct 10, 2024, at 11:49, sud wrote:
>
> Hi,
> I have never used any 'hash index' but saw documents in the past suggesting
> issues around hash index , like WAL doesnt generate for "hash index" which
> means we can't get the hash index back after crash also they are not applied
> to repl
Hi,
I have never used any 'hash index' but saw documents in the past suggesting
issues around hash index , like WAL doesnt generate for "hash index" which
means we can't get the hash index back after crash also they are not
applied to replicas etc. And also these indexes can not be used for range
q
11 matches
Mail list logo