> + { > + {"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.