On Tue, Aug 11, 2015 at 2:58 AM, Jeff Janes <jeff.ja...@gmail.com> wrote: > On Thu, Oct 30, 2014 at 5:30 AM, Fujii Masao <masao.fu...@gmail.com> wrote: >> >> On Thu, Oct 30, 2014 at 7:30 PM, Etsuro Fujita >> <fujita.ets...@lab.ntt.co.jp> wrote: >> >> > + { >> > + {"pending_list_cleanup_size", PGC_USERSET, >> > CLIENT_CONN_STATEMENT, >> > + gettext_noop("Sets the maximum size of the >> > pending >> > list for GIN index."), >> > + NULL, >> > + GUC_UNIT_KB >> > + }, >> > + &pending_list_cleanup_size, >> > + 4096, 0, MAX_KILOBYTES, >> > + NULL, NULL, NULL >> > + }, >> > >> > ISTM it'd be better to use RESOURCES_MEM, not CLIENT_CONN_STATEMENT. No? >> >> Yes if the pending list always exists in the memory. But not, IIUC. >> Thought? >> >> > Also why not set min to 64, not to 0, in accoradance with that of >> > work_mem? >> >> I'm OK to use 64. But I just chose 0 because I could not think of any >> reasonable >> reason why 64k is suitable as the minimum size of the pending list. >> IOW, I have no idea about whether it's reasonable to use the min value of >> work_mem as the min size of the pending list. > > > > I know I am late to the party here, but would like to have the minimum be 0, > not 64. As long as by zero, it means it doesn't insert anything into the > pending list, rather than inserting and promptly cleaning it up. > > The reason for this is that if I am trying to decide what > pending_list_cleanup_size I want to set for the index in the indexes storage > parameters, the way to find that out is try a bunch of different ones > through the guc while the index is still at the default of no overriding > storage parameter. It would be nice to try the fastupdate=off alternative > (i.e. the same as pending_list_cleanup_size=0) without having to change the > index itself and change the syntax used in the testing.
Sounds OK to me. So we should change the minimum values of both gin_pending_list_limit GUC and storage parameters to 0? Or only GUC? 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