On Tue, Aug 11, 2015 at 2:58 AM, Jeff Janes <jeff.janes@gmail.com> wrote:
> On Thu, Oct 30, 2014 at 5:30 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>>
>> On Thu, Oct 30, 2014 at 7:30 PM, Etsuro Fujita
>> <fujita.etsuro@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
