On Fri, Aug 4, 2017 at 9:19 AM, AP <a...@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:

> 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

Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:

Reply via email to