Received: from localhost (maia-5.hub.org [200.46.204.182]) by postgresql.org (Postfix) with ESMTP id 1B57D9FB62E for ; Tue, 8 May 2007 09:08:34 -0300 (ADT) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.182]) (amavisd-maia, port 10024) with ESMTP id 54086-04-4 for ; Tue, 8 May 2007 09:08:19 -0300 (ADT) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from mail.mnc.ch (62-2-77-205.static.cablecom.ch [62.2.77.205]) by postgresql.org (Postfix) with ESMTP id 28FC19FB58A for ; Tue, 8 May 2007 09:08:29 -0300 (ADT) Received: from localhost (localhost [127.0.0.1]) by mail.mnc.ch (Postfix) with ESMTP id 3DF4AA82EC for ; Tue, 8 May 2007 14:08:27 +0200 (CEST) Received: from mail.mnc.ch ([127.0.0.1]) by localhost (mail.test.lan [127.0.0.1]) (amavisd-new, port 10025) with ESMTP id 12115-02 for ; Tue, 8 May 2007 14:08:25 +0200 (CEST) Received: from meuh.mnc.lan (62-2-77-204.static.cablecom.ch [62.2.77.204]) by mail.mnc.ch (Postfix) with ESMTP id 26C93A818B for ; Tue, 8 May 2007 14:08:25 +0200 (CEST) Received: by meuh.mnc.lan (Postfix, from userid 1000) id E82321836AD; Tue, 8 May 2007 14:08:24 +0200 (CEST) To: pgsql-performance@postgresql.org Subject: estimating the need for VACUUM FULL and REINDEX X-Hashcash: 1:20:070508:pgsql-performance@postgresql.org::bIGlpPMD/kq1Jlqv:000000000000000000000000000002AxB From: Guillaume Cottenceau Date: 08 May 2007 14:08:24 +0200 Message-ID: <87odkvmsav.fsf@meuh.mnc.lan> Lines: 62 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.4 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Virus-Scanned: amavisd-new at mnc.ch X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200705/113 X-Sequence-Number: 24503 I'm trying to come up with a way to estimate the need for a VACUUM FULL and/or a REINDEX on some tables. According to documentation[1], VACUUM FULL's only benefit is returning unused disk space to the operating system; am I correct in assuming there's also the benefit of optimizing the performance of scans, because rows are physically compacted on the disk? With that in mind, I've tried to estimate how much benefit would be brought by running VACUUM FULL, with the output of VACUUM VERBOSE. However, it seems that for example the "removable rows" reported by each VACUUM VERBOSE run is actually reused by VACUUM, so is not what I'm looking for. Then according to documentation[2], REINDEX has some benefit when all but a few index keys on a page have been deleted, because the page remains allocated (thus, I assume it improves index scan performance, am I correct?). However, again I'm unable to estimate the expected benefit. With a slightly modified version of a query found in documentation[3] to see the pages used by a relation[4], I'm able to see that the index data from a given table... relname | relpages | reltuples ------------------------+----------+----------- idx_sessions_owner_key | 38 | 2166 pk_sessions | 25 | 2166 ...is duly optimized after a REINDEX: relname | relpages | reltuples ------------------------+----------+----------- idx_sessions_owner_key | 13 | 2166 pk_sessions | 7 | 2166 but what I'd need is really these 38-13 and 25-7 figures (or estimates) prior to running REINDEX. Thanks for any insight. Ref: [1] http://www.postgresql.org/docs/8.2/interactive/routine-vacuuming.html [2] http://www.postgresql.org/docs/8.2/interactive/routine-reindex.html [3] http://www.postgresql.org/docs/8.2/interactive/disk-usage.html [4] SELECT c2.relname, c2.relpages, c2.reltuples FROM pg_class c, pg_class c2, pg_index i WHERE c.relname = 'sessions' AND c.oid = i.indrelid AND c2.oid = i.indexrelid ORDER BY c2.relname; -- Guillaume Cottenceau, MNC Mobile News Channel SA, an Alcatel-Lucent Company Av. de la Gare 10, 1003 Lausanne, Switzerland - direct +41 21 317 50 36