Re: PENDING_LIST_CLEANUP_SIZE - maximum size of GIN pending list Re: HEAD seems to generate larger WAL regarding GIN index
От | Etsuro Fujita |
---|---|
Тема | Re: PENDING_LIST_CLEANUP_SIZE - maximum size of GIN pending list Re: HEAD seems to generate larger WAL regarding GIN index |
Дата | |
Msg-id | 540FC25F.6040404@lab.ntt.co.jp обсуждение исходный текст |
Ответ на | Re: PENDING_LIST_CLEANUP_SIZE - maximum size of GIN pending list Re: HEAD seems to generate larger WAL regarding GIN index (Fujii Masao <masao.fujii@gmail.com>) |
Ответы |
Re: PENDING_LIST_CLEANUP_SIZE - maximum size of GIN pending list Re:
HEAD seems to generate larger WAL regarding GIN index
|
Список | pgsql-hackers |
(2014/09/09 22:17), Fujii Masao wrote: > On Tue, Sep 9, 2014 at 1:28 AM, Jeff Janes <jeff.janes@gmail.com> wrote: >> I get some compiler warnings on v2 of this patch: >> >> reloptions.c:219: warning: excess elements in struct initializer >> reloptions.c:219: warning: (near initialization for 'intRelOpts[15]') > Attached is the updated version of the patch. Thank you for updating the patch! I took a quick review on the patch. It looks good to me, but one thing I'm concerned about is You wrote:>>>> The attached patch introduces the GIN index storage parameter>>>> "PENDING_LIST_CLEANUP_SIZE" which specifiesthe 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 thethreshold of cleanup operation of>>>> the pending list. It has only not to set PENDING_LIST_CLEANUP_SIZE. As you mentioned, I think it's important to consider for the existing applications, but I'm wondering if it would be a bit confusing users to have two parameters, PENDING_LIST_CLEANUP_SIZE and work_mem, for this setting. Wouldn't it be easy-to-use to have only one parameter, PENDING_LIST_CLEANUP_SIZE? How about setting PENDING_LIST_CLEANUP_SIZE to work_mem as the default value when running the CREATE INDEX command? Sorry for the delay. Best regards, Etsuro Fujita
В списке pgsql-hackers по дате отправления: