On Wed, Feb 24, 2016 at 9:17 AM, Tomas Vondra
<tomas.von...@2ndquadrant.com> wrote:
>> Well, turns out there's a quite significant difference, actually. The
>> index sizes I get (quite stable after multiple runs):
>>
>>     9.5 : 2428 MB
>>     9.6 + alone cleanup : 730 MB
>>     9.6 + pending lock : 488 MB
>>
>> So that's quite a significant difference, I guess. The load duration for
>> each version look like this:
>>
>>     9.5                 : 1415 seconds
>>     9.6 + alone cleanup : 1310 seconds
>>     9.6 + pending lock  : 1380 seconds
>>
>> I'd say I'm happy with sacrificing ~5% of time in exchange for ~35%
>> reduction of index size.
>>
>> The size of the index on 9.5 after VACUUM FULL (so pretty much the
>> smallest index possible) is 440MB, which suggests the "pending lock"
>> patch does a quite good job.
>>
>> The gin_metapage_info at the end of one of the runs (pretty much all the
>> runs look exactly the same) looks like this:
>>
>>                    pending lock   alone cleanup      9.5
>> --------------------------------------------------------
>>   pending_head                2               2   310460
>>   pending_tail              338             345   310806
>>   tail_free_size            812             812      812
>>   n_pending_pages           330             339      347
>>   n_pending_tuples         1003            1037     1059
>>   n_total_pages               2               2        2
>>   n_entry_pages               1               1        1
>>   n_data_pages                0               0        0
>>   n_entries                   0               0        0
>>   version                     2               2        2
>>
>> So almost no difference, except for the pending_* attributes, and even
>> in that case the values are only different for 9.5 branch. Not sure what
>> conclusion to draw from this - maybe it's necessary to collect the
>> function input while the load is running (but that'd be tricky to
>> process, I guess).
>
> Are we going to anything about this? While the bug is present in 9.5 (and
> possibly other versions), fixing it before 9.6 gets out seems important
> because reproducing it there is rather trivial (while I've been unable to
> reproduce it on 9.5).

I'm not going to promise to commit anything here, because GIN is not
usually my area, but could you provide a link to the email that
contains the patch you think should be committed?

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company


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

Reply via email to