Horton

Re: pgsql 10: hash indexes testing

Amit Kapila <amit.kapila16@gmail.com>

View thread View on postgr.es
From: Amit Kapila <amit.kapila16@gmail.com>
To: AP <ap@zip.com.au>
Cc: Robert Haas <robertmhaas@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-08-11T02:05:48Z
Lists: pgsql-hackers 
On Fri, Aug 11, 2017 at 5:01 AM, AP <ap@zip.com.au> wrote:
> On Thu, Aug 10, 2017 at 01:12:25PM -0400, Robert Haas wrote:
>> On Thu, Aug 10, 2017 at 6:41 AM, AP <ap@zip.com.au> wrote:
>> > The index is 135GB rather than 900GB (from memory/give or take).
>>
>> Whoa.  Big improvement.
>
>
> As an aside, btree for the above is around 2.5x bigger than hash v4 so
> chances are much better that a hash index will fit into ram which has
> its own benefits. :)
>

Yeah, that's exactly one of the benefit hash indexes can provide over
btree indexes.


-- 
With Regards,
Amit Kapila.
EnterpriseDB: http://www.enterprisedb.com

Commits

  1. pgstatindex: Insert some casts to prevent overflow.

  2. hash: Immediately after a bucket split, try to clean the old bucket.

  3. hash: Increase the number of possible overflow bitmaps by 8x.

  4. BRIN auto-summarization