Re: PENDING_LIST_CLEANUP_SIZE - maximum size of GIN pending list Re: HEAD seems to generate larger WAL regarding GIN index

On Fri, Aug 8, 2014 at 11:45 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
> On Fri, Aug 8, 2014 at 11:43 PM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:
>> On Mon, Apr 14, 2014 at 11:40 PM, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> wrote:
>>> Fujii Masao <masao(dot)fujii(at)gmail(dot)com> writes:
>>>> On Tue, Apr 1, 2014 at 1:41 AM, Robert Haas <robertmhaas(at)gmail(dot)com> wrote:
>>>>> Should we try to install some hack around fastupdate for 9.4? I fear
>>>>> the divergence between reasonable values of work_mem and reasonable
>>>>> sizes for that list is only going to continue to get bigger. I'm sure
>>>>> there's somebody out there who has work_mem = 16GB, and stuff like
>>>>> 263865a48973767ce8ed7b7788059a38a24a9f37 is only going to increase the
>>>>> appeal of large values.
>>>
>>>> Controlling the threshold of the size of pending list only by GUC doesn't
>>>> seem reasonable. Users may want to increase the threshold only for the
>>>> GIN index which can be updated heavily, and decrease it otherwise. So
>>>> I think that it's better to add new storage parameter for GIN index to control
>>>> the threshold, or both storage parameter and GUC.
>>>
>>> Yeah, -1 for a GUC. A GIN-index-specific storage parameter seems more
>>> appropriate.
>>
>> The attached patch introduces the GIN index storage parameter
>> "PENDING_LIST_CLEANUP_SIZE" which specifies the maximum size of
>> GIN pending list. If it's not set, work_mem is used as that maximum size,
>> instead. So this patch doesn't break the existing application which
>> currently uses work_mem as the threshold of cleanup operation of
>> the pending list. It has only not to set PENDING_LIST_CLEANUP_SIZE.
>>
>> This is an index storage parameter, and allows us to specify each
>> threshold per GIN index. So, for example, we can increase the threshold
>> only for the GIN index which can be updated heavily, and decrease it otherwise.
>>
>> This patch uses another patch that I proposed (*1) as an infrastructure.
>> Please apply that infrastructure patch first if you apply this patch.
>>
>> (*1)
>> http://www.postgresql.org/message-id/CAHGQGwEanQ_e8WLHL25=bm_8Z5zkyZw0K0yiR+kdMV2HgnE9FQ@mail.gmail.com
>>
>> Regards,
>>
>> --
>> Fujii Masao
>
> Sorry, I forgot to attached the patch.... This time, attached.
>

I think that this patch should be rebased.
It contains garbage code.

Regards,

-------
Sawada Masahiko