Received: from malur.postgresql.org ([217.196.149.56]) by arkaria.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UhkSv-00018D-LM for pgsql-performance@arkaria.postgresql.org; Wed, 29 May 2013 17:47:13 +0000 Received: from localhost ([127.0.0.1] helo=postgresql.org) by malur.postgresql.org with smtp (Exim 4.72) (envelope-from ) id 1UhkSu-0004UG-UI for pgsql-performance@arkaria.postgresql.org; Wed, 29 May 2013 17:47:12 +0000 Received: from makus.postgresql.org ([2001:4800:7903:4::125]) by malur.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1UhkSt-0004U8-Pu for pgsql-performance@postgresql.org; Wed, 29 May 2013 17:47:11 +0000 Received: from mail.simkin.ca ([72.51.27.125]) by makus.postgresql.org with esmtp (Exim 4.80) (envelope-from ) id 1UhkSo-00069R-EN for pgsql-performance@postgresql.org; Wed, 29 May 2013 17:47:11 +0000 Received: from vpn.reinvent.com (vpn.reinvent.com [72.51.27.50]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.simkin.ca (Postfix) with ESMTPSA id 98C522700BA for ; Wed, 29 May 2013 10:47:05 -0700 (PDT) From: Alan Hodgson To: pgsql-performance@postgresql.org Subject: Re: Best practice when reindexing in production Date: Wed, 29 May 2013 10:47:04 -0700 Message-ID: <1514687.3ZLd7LDGHi@skynet.simkin.ca> User-Agent: KMail/4.10.2 (Linux/3.8.13-gentoo; KDE/4.10.2; x86_64; ; ) In-Reply-To: <1369848321.28819.31.camel@risotto.smithersbet.com> References: <5359686B-FAE8-4056-AF13-F9FD6919FE82@autouncle.com> <51A63717.7070301@krogh.cc> <1369848321.28819.31.camel@risotto.smithersbet.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Pg-Spam-Score: -0.3 (/) List-Archive: List-Help: List-ID: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: X-Mailing-List: pgsql-performance Precedence: bulk Sender: pgsql-performance-owner@postgresql.org On Wednesday, May 29, 2013 06:25:21 PM Daniele Varrazzo wrote: > My solution has been to become pg_repack maintainer. YMMV. Just don't > expect vacuum to reduce the indexes size: it doesn't. It's not supposed to. It is supposed to keep them from indefinitely growing, though, which it does reasonably well at. -- Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-performance