Re: PENDING_LIST_CLEANUP_SIZE - maximum size of GIN pending list Re: HEAD seems to generate larger WAL regarding GIN index

On Thu, Oct 30, 2014 at 5:30 AM, Fujii Masao <masao(dot)fujii(at)gmail(dot)com> wrote:

> On Thu, Oct 30, 2014 at 7:30 PM, Etsuro Fujita
> <fujita(dot)etsuro(at)lab(dot)ntt(dot)co(dot)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.

Cheers,

Jeff