On Mon, Apr 14, 2014 at 11:40 PM, Tom Lane <tgl@sss.pgh.pa.us> wrote:
> Fujii Masao <masao.fujii@gmail.com> writes:
>> On Tue, Apr 1, 2014 at 1:41 AM, Robert Haas <robertmhaas@gmail.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
