Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 9DF36B5DBC4 for ; Wed, 19 Oct 2011 23:51:13 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 86056-06 for ; Thu, 20 Oct 2011 02:51:07 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0-rc2 Received: from mail-gy0-f174.google.com (mail-gy0-f174.google.com [209.85.160.174]) by mail.postgresql.org (Postfix) with ESMTP id 9427BB5D80B for ; Wed, 19 Oct 2011 23:51:07 -0300 (ADT) Received: by gyb13 with SMTP id 13so2328165gyb.19 for ; Wed, 19 Oct 2011 19:51:07 -0700 (PDT) Received: by 10.182.73.36 with SMTP id i4mr1549774obv.24.1319079067801; Wed, 19 Oct 2011 19:51:07 -0700 (PDT) Received: from [192.168.1.102] (c-69-181-249-16.hsd1.ca.comcast.net. [69.181.249.16]) by mx.google.com with ESMTPS id l9sm574277oba.9.2011.10.19.19.51.06 (version=SSLv3 cipher=OTHER); Wed, 19 Oct 2011 19:51:07 -0700 (PDT) Message-ID: <1319079069.16256.42.camel@jdavis> Subject: Re: delete/recreate indexes From: Jeff Davis To: alan Cc: pgsql-performance@postgresql.org Date: Wed, 19 Oct 2011 19:51:09 -0700 In-Reply-To: <727c5bc3-0bab-490f-add7-6eed47627ee5@ff5g2000vbb.googlegroups.com> References: <727c5bc3-0bab-490f-add7-6eed47627ee5@ff5g2000vbb.googlegroups.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.2.0- Content-Transfer-Encoding: 8bit Mime-Version: 1.0 X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201110/172 X-Sequence-Number: 45394 On Wed, 2011-10-19 at 08:03 -0700, alan wrote: > So I thought I’d just run this once (via cron) every morning. > BEGIN; > DROP INDEX data_unique; > UPDATE data SET datum = (data.datum + interval '24 hours'); > CREATE UNIQUE INDEX data_unique ON public.data USING BTREE > (device, group, datum); > COMMIT; > > But > 1. it’s taking forever and > 2. I’m seeing that my disk is filling up real fast. An unrestricted update will end up rewriting the whole table. It's advisable to run VACUUM afterward, so that the wasted space can be reclaimed. What version are you on? Do you have autovacuum enabled? Also, to take a step back, why do you try to keep the timestamps changing like that? Why not store the information you need in the record (e.g. insert time as well as the datum) and then compute the result you need using a SELECT (or make it a view for convenience)? Fundamentally, these records aren't changing, you are just trying to interpret them in the context of the current day. That should be done using a SELECT, not an UPDATE. Regards, Jeff Davis