X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 7E6EB52C48 for ; Mon, 25 Jul 2005 20:31:22 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 25483-03 for ; Mon, 25 Jul 2005 23:31:13 +0000 (GMT) Received: from sccmmhc92.asp.att.net (sccmmhc92.asp.att.net [204.127.203.212]) by svr1.postgresql.org (Postfix) with ESMTP id 5D18452FE9 for ; Mon, 25 Jul 2005 20:31:12 -0300 (ADT) Received: from juju.arbash-meinel.com ([12.214.18.81]) by sccmmhc92.asp.att.net (sccmmhc92) with ESMTP id <20050725233116m9200g50sde>; Mon, 25 Jul 2005 23:31:16 +0000 Received: by juju.arbash-meinel.com (Postfix, from userid 505) id 614E75600C; Mon, 25 Jul 2005 18:31:15 -0500 (CDT) Received: from [192.168.1.112] (71-32-73-140.cdrr.qwest.net [71.32.73.140]) by juju.arbash-meinel.com (Postfix) with ESMTP id B59EE55FB5; Mon, 25 Jul 2005 18:31:11 -0500 (CDT) Message-ID: <42E5763C.7030804@arbash-meinel.com> Date: Mon, 25 Jul 2005 18:31:08 -0500 From: John A Meinel User-Agent: Mozilla Thunderbird 1.0.6 (Macintosh/20050716) X-Accept-Language: en-us, en MIME-Version: 1.0 To: "Tomeh, Husam" Cc: Luke Lonergan , pgsql-performance@postgresql.org Subject: Re: "Vacuum Full Analyze" taking so long References: In-Reply-To: X-Enigmail-Version: 0.92.0.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enig4E54487029FFB447F5276BE0" X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.045 tagged_above=0 required=5 tests=AWL, FORGED_RCVD_HELO X-Spam-Level: X-Archive-Number: 200507/379 X-Sequence-Number: 13620 This is an OpenPGP/MIME signed message (RFC 2440 and 3156) --------------enig4E54487029FFB447F5276BE0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Tomeh, Husam wrote: > > Nothing was running except the job. The server did not look stressed out > looking at top and vmstat. We have seen slower query performance when > performing load tests, so I run the re-index on all application indexes > and then issue a full vacuum. I ran the same thing on a staging server > and it took less than 12 hours. Is there a possibility the DB pages are > corrupted. Is there a command to verify that. (In Oracle, there's a > dbverify command that checks for corruption on the data files level). > > The other question I have. What would be the proper approach to rebuild > indexes. I re-indexes and then run vacuum/analyze. Should I not use the > re-index approach, and instead, drop the indexes, vacuum the tables, and > then create the indexes, then run analyze on tables and indexes?? I *think* if you are planning on dropping the indexes anyway, just drop them, VACUUM ANALYZE, and then recreate them, I don't think you have to re-analyze after you have recreated them. John =:-> > > Thanks, > > --------------enig4E54487029FFB447F5276BE0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFC5XY9JdeBCYSNAAMRAip9AKClCCUdHAiQHR1kfGxOqBXhgBbv5QCgnxhV DVswER6oKm+snqzCAuuLXgk= =vFll -----END PGP SIGNATURE----- --------------enig4E54487029FFB447F5276BE0--