Re: pgsql 10: hash indexes testing
AP <ap@zip.com.au>
From: AP <ap@zip.com.au>
To: Robert Haas <robertmhaas@gmail.com>
Cc: Amit Kapila <amit.kapila16@gmail.com>, Alvaro Herrera <alvherre@2ndquadrant.com>, pgsql-hackers <pgsql-hackers@postgresql.org>
Date: 2017-08-10T23:31:52Z
Lists: 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
Commits
-
pgstatindex: Insert some casts to prevent overflow.
- 0b7ba3d6474b 10.0 cited
-
hash: Immediately after a bucket split, try to clean the old bucket.
- ff98a5e1e49d 10.0 landed
-
hash: Increase the number of possible overflow bitmaps by 8x.
- 620b49a16d2a 10.0 landed
-
BRIN auto-summarization
- 7526e10224f0 10.0 cited