Received: from localhost (unknown [200.46.204.183]) by postgresql.org (Postfix) with ESMTP id 4D7F52E006B for ; Sun, 2 Dec 2007 16:51:35 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.183]) (amavisd-maia, port 10024) with ESMTP id 09692-06 for ; Sun, 2 Dec 2007 16:51:26 -0400 (AST) Received: from nf-out-0910.google.com (nf-out-0910.google.com [64.233.182.184]) by postgresql.org (Postfix) with ESMTP id F40102E0041 for ; Sun, 2 Dec 2007 16:51:25 -0400 (AST) Received: by nf-out-0910.google.com with SMTP id f5so2159250nfh for ; Sun, 02 Dec 2007 12:51:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; bh=iGOj8DTPxlInc3YyE+mpNIhOeS7sSm66mY9bN78+mDs=; b=jChAaQUQ+lNsSD8uLW5HoAcrzfT+FWc5S0M96T5A6HTAPr4lCASxxz6Fbcx8EZUJnJeP7YXWb9rAufI8Ihf4JAA/2kNX8PXjWlHMkrTRV5Uy1rCIZAuc1e86Zy62YFX5oQft+eRVLUy1MoMSM+a8E02qwq9drhVTpuaqmLsAj4o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=rjA+i0tfK9lCBDd3VQAdMNT/cqpr89UHdgQ+CM/T68lGjpDyznrBltzSUF212/JfwNG/vIUY/dn+pmKQWV7UwbJz2rOOiORQpxhgeqBiX/GYitmb+ATSlvwda4nyPEZN9OAdKfBKXkWztWe4q/owaQn4Kssks+4VOOJoGQ81g7M= Received: by 10.78.193.5 with SMTP id q5mr5923393huf.1196628683786; Sun, 02 Dec 2007 12:51:23 -0800 (PST) Received: by 10.78.151.9 with HTTP; Sun, 2 Dec 2007 12:51:23 -0800 (PST) Message-ID: Date: Mon, 3 Dec 2007 01:51:23 +0500 From: "Usama Dar" To: "Alvaro Herrera" Subject: Re: Enhancement request Cc: "Joshua D. Drake" , "Tom Lane" , "Jonah H. Harris" , "Campbell, Lance" , "posgres support" In-Reply-To: <20071202013114.GB11039@alvh.no-ip.org> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_3343_26336637.1196628683769" References: <36e682920711301218m703b3c67s6f547fd7b9b60e7c@mail.gmail.com> <7099.1196458205@sss.pgh.pa.us> <36e682920711301332q1cce5db9qe44fb068fcd5608d@mail.gmail.com> <7341.1196459304@sss.pgh.pa.us> <20071130140005.18521c54@jd-laptop> <20071130223402.GG3175@alvh.no-ip.org> <20071201123029.5776b3c5@jd-laptop> <20071202013114.GB11039@alvh.no-ip.org> X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200712/3 X-Sequence-Number: 27520 ------=_Part_3343_26336637.1196628683769 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Dec 2, 2007 6:31 AM, Alvaro Herrera wrote: > Joshua D. Drake escribi=F3: > > On Fri, 30 Nov 2007 19:34:02 -0300 > > Alvaro Herrera wrote: > > > > > Joshua D. Drake escribi=C3=B3: > > > > > > > The multi-worker autovacuum is a great new addition to help part of > > > > that problem (starvation) but it is not help against the other > > > > (resource consumption, specifically IO). > > > > > > Huh, autovac will consume exactly the same amount of I/O as a > > > user-induced vacuum, so I don't see your point. > > > > It can be determined "when" the I/O is used. > > Future plans call for being able to change autovac parameters depending > on time of day, so you will be able to decide that using autovacuum too. > > > > Remember, we're not adding VACUUM SCHEMA in 8.2 so it doesn't make an= y > > > sense to try to compare it against the old autovac. And you can bet > > > that in 8.4 autovac will have even more goodies. > > > > I assume you mean 8.3, but that is certainly a valid point. > > No, I meant 8.4 --- the feature set of 8.3 is already set on stone. So > VACUUM SCHEMA has to compete with whatever we're able to do for the > release following that one. i think even when autovacuum is uber-perfect , the manual overriding commands like VACUUM and utilities like VACUUMDB will still exist for a lon= g time to come, so there is a case of improving them if required. Maybe it would be just easier to add a schema switch to VACUUMDB, which can just query the catalogs to find which tables to vacuum, this way no parser changes are involved or any tinkering with the backend code. > > -- > Alvaro Herrera > http://www.advogato.org/person/alvherre > "Entristecido, Wutra (canci=F3n de Las Barreras) > echa a Freyr a rodar > y a nosotros al mar" > > ---------------------------(end of broadcast)--------------------------- > TIP 3: Have you checked our extensive FAQ? > > http://www.postgresql.org/docs/faq > --=20 Usama Munir Dar http://linkedin.com/in/usamadar Consultant Architect Cell:+92 321 5020666 Skype: usamadar ------=_Part_3343_26336637.1196628683769 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline

On Dec 2, 2007 6:31 AM, Alvaro Herrera &= lt;alvherre@alvh.no-ip.org&g= t; wrote:
Joshua D. Drake escribi=F3:
> On Fri, 30 Nov 20= 07 19:34:02 -0300
> Alvaro Herrera <alvherre@alvh.no-ip.org> wrote:
>
> > Jo= shua D. Drake escribi=C3=B3:
> >
> > > The multi-worke= r autovacuum is a great new addition to help part of
> > > that= problem (starvation) but it is not help against the other
> > >= ; (resource consumption, specifically IO).
> >
> > Huh, autovac will consume exactly the same amoun= t of I/O as a
> > user-induced vacuum, so I don't see your poi= nt.
>
> It can be determined "when" the I/O is used.

Future plans call for being able to change autovac parameters= depending
on time of day, so you will be able to decide that using auto= vacuum too.

> > Remember, we're not = adding VACUUM SCHEMA in=20 8.2 so it doesn't make any
> > sense to try to compare it agai= nst the old autovac.  And you can bet
> > that in 8.4 autovac= will have even more goodies.
>
> I assume you mean 8.3, but th= at is certainly a valid point.

No, I meant 8.4 --- the feature set of 8.3 is already set on = stone.  So
VACUUM SCHEMA has to compete with whatever we're abl= e to do for the
release following that one.

i think= even when autovacuum is uber-perfect , the manual overriding commands like= VACUUM and utilities like VACUUMDB will still exist for a long time to com= e, so there is a case of improving them if required.  Maybe it would b= e just easier to add a schema switch to VACUUMDB, which can just query the = catalogs to find which tables to vacuum, this way no parser changes are inv= olved or any tinkering with the backend code.


--
Alvaro Herrera       &nbs= p;                 http://www.advogato.org/person/alvherre
"Entristecido, Wutra &n= bsp;                   (canci= =F3n de Las Barreras)
echa a Freyr a rodar
y a nosotros al mar"<= br>

---------------------------(end of broadcast)---------------------------TIP 3: Have you checked our extensive FAQ?

      &n= bsp;       http://www.postgresql.org/docs/faq



--
Usa= ma Munir Dar http://linkedin.co= m/in/usamadar
Consultant Architect
Cell:+92 321 5020666
Skype:= usamadar=20
------=_Part_3343_26336637.1196628683769--