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

Re: First steps with 8.3 and autovacuum launcher

From: Alvaro Herrera <alvherre(at)commandprompt(dot)com>
To: Heikki Linnakangas <heikki(at)enterprisedb(dot)com>
Cc: Gregory Stark <stark(at)enterprisedb(dot)com>, 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 19:59:16
Message-ID: 20071001195916.GE20792@alvh.no-ip.org (view raw or flat)
Thread:
Lists: pgsql-hackers
Heikki Linnakangas escribió:

> 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)?

This is an interesting idea, but I think it's attacking the wrong
problem.  To me, the problem here is that an ANALYZE should not block
CREATE INDEX or certain forms of ALTER TABLE.

We do have a mechanism for changing the cost-delay parameters of an
autovac worker, but even if we made it to work, it would still delay the
other operation needlessly until the end of the analyze.

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

In response to

Responses

pgsql-hackers by date

Next:From: Tom LaneDate: 2007-10-01 20:26:00
Subject: Re: First steps with 8.3 and autovacuum launcher
Previous:From: Brendan JurdDate: 2007-10-01 19:20:12
Subject: Re: [HACKERS] Text <-> C string

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