On Wed, Sep 10, 2014 at 12:15 PM, Etsuro Fujita <fujita.ets...@lab.ntt.co.jp> wrote: > (2014/09/09 22:17), Fujii Masao wrote: >> >> On Tue, Sep 9, 2014 at 1:28 AM, Jeff Janes <jeff.ja...@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,
Thanks for reviewing the patch! > but one thing I'm > concerned about is > > You wrote: >>>>> 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. > > 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, Yep. > 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? That's an idea. But there might be some users who want to change the cleanup size per session like they can do by setting work_mem, and your idea would prevent them from doing that... So what about introduing pending_list_cleanup_size also as GUC? That is, users can set the threshold by using either the reloption or GUC. > Sorry for the delay. No problem. Thanks! Regards, -- Fujii Masao -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
