Re: GIN data corruption bug(s) in 9.6devel

Поиск
Список
Период
Сортировка
От Robert Haas
Тема Re: GIN data corruption bug(s) in 9.6devel
Дата
Msg-id CA+TgmoZQuSCvPbLZ9P3ekhSDSdSX86Ha-=3f_GWSbrSWL6tyjg@mail.gmail.com
обсуждение исходный текст
Ответ на Re: GIN data corruption bug(s) in 9.6devel  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Ответы Re: GIN data corruption bug(s) in 9.6devel  (Tomas Vondra <tomas.vondra@2ndquadrant.com>)
Список pgsql-hackers
On Wed, Feb 24, 2016 at 9:17 AM, Tomas Vondra
<tomas.vondra@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



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Michael Paquier
Дата:
Сообщение: Re: Why vacuum_freeze_table_age etc. doc in "Statement Behavior" section?
Следующее
От: Robert Haas
Дата:
Сообщение: Re: significant semi join overestimates (with CTEs)