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 |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-10-01 20:26:00 | Re: First steps with 8.3 and autovacuum launcher |
Previous Message | Brendan Jurd | 2007-10-01 19:20:12 | Re: [HACKERS] Text <-> C string |