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

From Alvaro Herrera
Subject Re: PENDING_LIST_CLEANUP_SIZE - maximum size of GIN pending list Re: HEAD seems to generate larger WAL regarding GIN index
Date
Msg-id 20140910133742.GA4701@eldon.alvh.no-ip.org
Whole thread Raw
In response to Re: PENDING_LIST_CLEANUP_SIZE - maximum size of GIN pending list Re: HEAD seems to generate larger WAL regarding GIN index  (Fujii Masao <masao.fujii@gmail.com>)
Responses Re: PENDING_LIST_CLEANUP_SIZE - maximum size of GIN pending list Re: HEAD seems to generate larger WAL regarding GIN index
List pgsql-hackers
Fujii Masao wrote:
> On Wed, Sep 10, 2014 at 12:15 PM, Etsuro Fujita
> <fujita.etsuro@lab.ntt.co.jp> wrote:

> > 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.

Yes, I think having both a GUC and a reloption makes sense -- the GUC
applies to all indexes, and can be tweaked for individual indexes using
the reloption.

I'm not sure about the idea of being able to change it per session,
though.  Do you mean that you would like insert processes use a very
large value so that they can just append new values to the pending list,
and have vacuum use a small value so that it cleans up as soon as it
runs?  Two things: 1. we could have an "autovacuum_" reloption which
only changes what autovacuum does; 2. we could have autovacuum run
index cleanup actions separately from actual vacuuming.

-- 
Álvaro Herrera                http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services



pgsql-hackers by date:

Previous
From: Marko Tiikkaja
Date:
Subject: Re: pgcrypto: PGP armor headers
Next
From: Alvaro Herrera
Date:
Subject: Re: SKIP LOCKED DATA (work in progress)