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

Re: GIN improvements

From: Teodor Sigaev <teodor(at)sigaev(dot)ru>
To: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
Cc: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>, Patches <pgsql-patches(at)postgresql(dot)org>
Subject: Re: GIN improvements
Date: 2008-06-10 11:23:06
Message-ID: 484E641A.4060301@sigaev.ru (view raw or flat)
Thread:
Lists: pgsql-hackerspgsql-patches
> Perhaps we could make the fixed-size buffer be of size X, and trigger
> autovac on X/3 or some such, to give it enough slack so that it would be
> very unlikely to be processed by user processes.
>> Do you mean that GIN sends a "smoke signal" to the autovacuum launcher 
>> process to ask about vacuum?
> Currently, autovac only uses pgstats as trigger for actions.  Maybe we
> could use something else (say, a flag in shared memory?), or just stash
> the info that the index needs to be processed in pgstats and have
> autovac examine it.

Flag in pgstats or shared memory is most reasonable solution. Using size of 
buffers is not very good because other indexes might use another technics for 
delayed insert and use another trigger criteria.

Suppose, the best technic for GIN will be a setting flag by search procedure - 
if time of scanning pending pages is eqial to time of search in regular 
structure then it's time to call insert cleanup.


-- 
Teodor Sigaev                                   E-mail: teodor(at)sigaev(dot)ru
                                                    WWW: http://www.sigaev.ru/

In response to

pgsql-hackers by date

Next:From: Teodor SigaevDate: 2008-06-10 11:38:21
Subject: Re: GIN improvements
Previous:From: Zeugswetter Andreas OSB sITDate: 2008-06-10 10:16:59
Subject: Re: Proposal - improve eqsel estimates by including histogram bucket numdistinct statistics

pgsql-patches by date

Next:From: Teodor SigaevDate: 2008-06-10 11:38:21
Subject: Re: GIN improvements
Previous:From: Pavel StehuleDate: 2008-06-10 09:39:21
Subject: Re: SQL: table function support

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