Re: [HACKERS] pgsql 10: hash indexes testing - Mailing list pgsql-hackers

From AP
Subject Re: [HACKERS] pgsql 10: hash indexes testing
Date
Msg-id 20170810233151.vvph2h7rwceyzf7r@zip.com.au
Whole thread Raw
In response to Re: [HACKERS] pgsql 10: hash indexes testing  (Robert Haas <robertmhaas@gmail.com>)
Responses Re: [HACKERS] pgsql 10: hash indexes testing  (Amit Kapila <amit.kapila16@gmail.com>)
List pgsql-hackers
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.

Not a good direct comparison in general but it fits my workload.

The 900GB was fillfactor 10 and the 135 was ff 90 BUT ff 90 on
v3 fails early into the import. Even ff 10 on v3 didn't succeed (came just
short). So for my usage I was facing having indexes with fillfactor 10
just to be able to put a more reasonable amount of data in them. Almost.

Now I don't have to as v4 copes with the load and more and in less disk
space so for me, the above is just lovely. :) This is even more so
given that the hash index v4 upload actually finished unlike the v3 one. :)

As I said in my last email, this weekend I'll be adding more to that table
so I'll see how far that takes me but the last two patches have given
me a great deal of confidence that the end result will be good news. :)

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. :)

AP



pgsql-hackers by date:

Previous
From: Thomas Munro
Date:
Subject: Re: [HACKERS] Thoughts on unit testing?
Next
From: Thomas Munro
Date:
Subject: Re: [HACKERS] Thoughts on unit testing?