Re: pgsql 10: hash indexes testing
Amit Kapila <amit.kapila16@gmail.com>
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-04T10:31:11Z
Lists: pgsql-hackers
On Fri, Aug 4, 2017 at 9:19 AM, AP <ap@zip.com.au> wrote: > On Fri, Aug 04, 2017 at 08:21:01AM +0530, Amit Kapila wrote: >> Note - AP has off list shared the data dump and we (Ashutosh Sharma >> and me) are able to reproduce the problem and we could see that if we >> force vacuum via the debugger, then it is able to free overflow pages. >> The exact numbers are not available at this stage as the test is not >> complete. > > I've another if you would like it. I COPYed with FILLFACTOR of 10 and > it eventually failed but I could not recreate the index (via CREATE INDEX > CONCURRENTLY) with the data that made it using a fillfactor of 100. If > I created the index again (again with the same data) with fillfactor 10 > then it completed. > > I may be completely misunderstanding fillfactor but I always thought it was > a performance optimisation rather than something that may allow you to store > more (or less) index entries. > It impacts the split behavior. You can read about it at: https://www.postgresql.org/docs/9.6/static/sql-createindex.html > > The DB in question is now gone but I took a copy of the column as per > before so if you'd like it I can make it available via the same means. > Can you try with the patches posted above? -- With Regards, Amit Kapila. EnterpriseDB: http://www.enterprisedb.com
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