Skip site navigation (1) Skip section navigation (2)

Re: [PATCHES] GIN improvements

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com>, Teodor Sigaev <teodor(at)sigaev(dot)ru>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, Pgsql Hackers <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: [PATCHES] GIN improvements
Date: 2008-11-28 00:22:35
Message-ID: 20081128002235.GN4586@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
Gregory Stark wrote:
> Heikki Linnakangas <heikki(dot)linnakangas(at)enterprisedb(dot)com> writes:
> 
> > I think we need a hard limit on the number of list pages, before we can
> > consider accepting this patch. After the limit is full, the next inserter can
> > flush the list, inserting the tuples in the list into the tree, or just fall
> > back to regular, slow, inserts.
> 
> I do like the idea of having the work fall to vacuum though. Perhaps we need
> some way for autovacuum to ask an access method what shape an index is in and
> whether it needs vacuuming? Or more likely a separate command from vacuum that
> specifically cleans up an index.

Yeah, this is what we agreed to on Ottawa.  We need to collect some
different stats for the GIN indexes where this is active, and ensure
that autovacuum checks them.

-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

In response to

pgsql-hackers by date

Next:From: Fujii MasaoDate: 2008-11-28 02:45:19
Subject: Synchronous replication patch v4
Previous:From: Gregory StarkDate: 2008-11-27 23:46:35
Subject: Re: Simple postgresql.conf wizard

pgsql-patches by date

Next:From: Teodor SigaevDate: 2008-12-02 12:56:33
Subject: Re: [PATCHES] GIN improvements
Previous:From: Gregory StarkDate: 2008-11-27 22:14:59
Subject: Re: [PATCHES] GIN improvements

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group