Re: Reverse Key Index

From: "Sven R(dot) Kunze" <srkunze(at)tbz-pariv(dot)de>
To: Josh Berkus <josh(at)agliodbs(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: pgsql-performance(at)postgresql(dot)org
Subject: Re: Reverse Key Index
Date: 2015-02-26 11:04:01
Message-ID: 54EEFDA1.7020609@tbz-pariv.de
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

On 25.02.2015 23:31, Josh Berkus wrote:
> On 02/14/2015 10:35 AM, Sven R. Kunze wrote:
>> Thanks for the immediate reply.
>>
>> I understand the use case is quite limited.
>>
>> On the other hand, I see potential when it comes to applications which
>> use PostgreSQL. There, programmers would have to change a lot of code to
>> tweak existing (and more importantly working) queries to hash/reverse an
>> id column first. Using ORMs would make this change even more painful and
>> maybe even impossible.
>>
>> When reading
>> https://richardfoote.wordpress.com/2008/01/14/introduction-to-reverse-key-indexes-part-i/
>> carefully, it also seems to work with index scan partially in case of
>> equality comparisons.
> Seems like a good use for SP-GiST. Go for it!
>

I just thought about btree indexes here mainly because they well-known
and well-used in ORM frameworks. Considering the documentation and
third-party posts on GiST and btree_gist, at least to me, it seems as if
people would not want to use that for integers; which in turn is the
main use-case scenario for reverse key indexes.

--
Sven R. Kunze
TBZ-PARIV GmbH, Bernsdorfer Str. 210-212, 09126 Chemnitz
Tel: +49 (0)371 33714721, Fax: +49 (0)371 5347920
e-mail: srkunze(at)tbz-pariv(dot)de
web: www.tbz-pariv.de

Geschäftsführer: Dr. Reiner Wohlgemuth
Sitz der Gesellschaft: Chemnitz
Registergericht: Chemnitz HRB 8543

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Thomas Kellerer 2015-02-26 11:45:46 Re: Reverse Key Index
Previous Message Sergey Shchukin 2015-02-26 06:25:31 Re: [pgadmin-support] Issue with a hanging apply process on the replica db after vacuum works on primary