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

Re: First steps with 8.3 and autovacuum launcher

From: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
To: Gregory Stark <stark(at)enterprisedb(dot)com>
Cc: Stefan Kaltenbrunner <stefan(at)kaltenbrunner(dot)cc>, Guillaume Smet <guillaume(dot)smet(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org>
Subject: Re: First steps with 8.3 and autovacuum launcher
Date: 2007-10-01 17:42:41
Message-ID: (view raw, whole thread or download thread mbox)
Lists: pgsql-hackers
Gregory Stark wrote:
> "Stefan Kaltenbrunner" <stefan(at)kaltenbrunner(dot)cc> writes:
>> some additional datapoints:
>> autovacuum on, delay 20: 8h 40min
>> autovacuum on, delay 0: 4h 23min
> I realize this isn't directly addressing the problem but perhaps part of the
> solution would be to start advocating the use of pg_restore -1 ? That would
> solve the problem for the narrow case of pg_restore.
> In the long run we could think about exposing some kind of command for
> pg_restore to use which would disable autovacuum from touching a table. (Or
> take a session-level lock on the table -- shudder)

In my opinion, CREATE INDEX shouldn't need to wait for autovacuum to
finish, regardless of who issued it. This is like priority inversion;
the autovacuum is not urgent, and runs slowly to avoid disturbing
others. But if it keeps the higher priority CREATE INDEX from starting,
it is disturbing others. Could we arrange things so that the effective
cost delay of the autovacuum process that's in the way gets set to 0
(like priority inheritance)?

  Heikki Linnakangas

In response to


pgsql-hackers by date

Next:From: Andrew DunstanDate: 2007-10-01 18:09:01
Subject: Re: adding operators
Previous:From: Tom LaneDate: 2007-10-01 17:35:41
Subject: Re: First steps with 8.3 and autovacuum launcher

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