X-Original-To: pgsql-advocacy-postgresql.org@localhost.postgresql.org
Received: from localhost (unknown [200.46.204.2])
	by svr1.postgresql.org (Postfix) with ESMTP
	id D8910D1D3BE; Fri, 23 Apr 2004 10:58:23 -0300 (ADT)
Received: from svr1.postgresql.org ([200.46.204.71])
	by localhost (neptune.hub.org [200.46.204.2]) (amavisd-new, port 10024)
	with ESMTP id 26346-03; Fri, 23 Apr 2004 10:58:26 -0300 (ADT)
Received: from outbound.mailhop.org (outbound.mailhop.org [63.208.196.171])
	by svr1.postgresql.org (Postfix) with ESMTP
	id C990FD1D621; Fri, 23 Apr 2004 10:58:21 -0300 (ADT)
Received: from ool-4352919e.dyn.optonline.net ([67.82.145.158]
	helo=matth.zeut.net) by outbound.mailhop.org with asmtp (Exim 4.20)
	id 1BH1By-000BpB-1r; Fri, 23 Apr 2004 09:58:10 -0400
Received: from 192.154.91.225 (SquirrelMail authenticated user dbmail2user);
	by matth.zeut.net with HTTP; Fri, 23 Apr 2004 08:58:41 -0400 (EDT)
Message-ID: <58232.192.154.91.225.1082725121.squirrel@192.154.91.225>
In-Reply-To: <Pine.LNX.4.58.0404230935570.6454@sablons.cri.ensmp.fr>
References: <200404230409.i3N49jC02890@candle.pha.pa.us>
	<Pine.LNX.4.58.0404230935570.6454@sablons.cri.ensmp.fr>
Date: Fri, 23 Apr 2004 08:58:41 -0400 (EDT)
Subject: Re: [HACKERS] What can we learn from MySQL?
From: "Matthew T. O'Connor" <matthew@zeut.net>
To: "Fabien COELHO" <coelho@cri.ensmp.fr>
Cc: "Bruce Momjian" <pgman@candle.pha.pa.us>,
	"PostgreSQL-development" <pgsql-hackers@postgresql.org>,
	"PostgreSQL advocacy" <pgsql-advocacy@postgresql.org>
User-Agent: SquirrelMail/1.5.0
MIME-Version: 1.0
Content-Type: text/plain;charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Priority: 3
Importance: Normal
X-Mail-Handler: MailHop Outbound by DynDNS.org
X-Report-Abuse-To: abuse@dyndns.org
X-MHO-User: Zeut
X-Virus-Scanned: by amavisd-new at postgresql.org
X-Spam-Status: No, hits=1.0 tagged_above=0.0 required=5.0
	tests=PRIORITY_NO_NAME, RCVD_IN_NJABL, RCVD_IN_SORBS
X-Spam-Level: *
X-Archive-Number: 200404/217
X-Sequence-Number: 4189

> There are two issues here : ease-of-use for admin and basic users.
>
> On for former point, admin ease-of-use, A little story a few month ago.
>
> I succeeded in advising production people here to switch some applications
> from a mysql database, which was working perfectly, to a postgres
> database. A few weeks later, the performances were desastrous. 30 seconds
> to get an answer to a simple select on a 1500 entries tables. After
> investigation, the problems were:
>
>  - no vacuum, although there were daily "DELETE FROM tables;"
>    to empty all the data and reload from another source.
>
>  - no analyze, because the admin did not know about it.

My goal is to have pg_autovacuum integrated into the backend for 7.5.  I
don't know if it will default to being turned on or off, I'm sure that
will be a discussion, but if it is defaulted to on, then this whole
problem of having to train newbies about vacuum should just go away.

Matthew