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

On Sat, Aug 16, 2014 at 4:23 PM, Sawada Masahiko <sawada(dot)mshk(at)gmail(dot)com> wrote:
> 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.

Thanks for reviewing the patch! ISTM that I failed to make the patch from
my git repository... Attached is the rebased version.

Regards,

--
Fujii Masao