Received: from magus.postgresql.org (magus.postgresql.org [87.238.57.229]) by mail.postgresql.org (Postfix) with ESMTP id D527D1EB83EC for ; Thu, 23 Feb 2012 11:44:51 -0400 (AST) Received: from news.hub.org ([200.46.204.72]) by magus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1S0aqc-0000hT-B8 for pgsql-performance@postgresql.org; Thu, 23 Feb 2012 15:44:50 +0000 Received: from news.hub.org (news.hub.org [200.46.204.72]) by news.hub.org (8.14.4/8.14.4) with ESMTP id q1NFiWv6002588 for ; Thu, 23 Feb 2012 11:44:32 -0400 (AST) (envelope-from news@news.hub.org) Received: (from news@localhost) by news.hub.org (8.14.4/8.14.4/Submit) id q1NFgFnT000502 for pgsql-performance@postgresql.org; Thu, 23 Feb 2012 11:42:15 -0400 (AST) (envelope-from news) From: Lew X-Newsgroups: pgsql.performance Subject: Re: Very long deletion time on a 200 GB database Date: Thu, 23 Feb 2012 07:42:12 -0800 Organization: albasani.net Lines: 31 Message-ID: References: <4F45FB55.1020600@lerner.co.il> <4F464C49.4050503@dunslane.net> <4F465A7A.4000905@lerner.co.il> <20120223152837.GV21114@aart.rice.edu> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: news.albasani.net; logging-data="cwLcEwpM5uFuijfPI1CyQ49zO40weWgj9lDKCCIF1zpavhXZa+NxyFuQXsFm+mMobE5JQ1Rk7siknQ4f054GzTsxmbrUhWNOnL2uDkD87fLAc18fd9tNhLZ+ihUc2ZzG"; mail-complaints-to="abuse@albasani.net" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 In-Reply-To: <20120223152837.GV21114@aart.rice.edu> Cancel-Lock: sha1:Okmw0+tO7cpyBfaC9V8BJC4wnSM= To: pgsql-performance@postgresql.org X-Pg-Spam-Score: -1.9 (-) X-Archive-Number: 201202/193 X-Sequence-Number: 46365 On 02/23/2012 07:28 AM, ktm@rice.edu wrote: > On Thu, Feb 23, 2012 at 05:25:46PM +0200, Reuven M. Lerner wrote: >>> >>> What is the distribution of end_dates? It might be worth running this in >>> several steps, deleting records older than, say, 90 days, 60 days, 30 days. >> >> I've suggested something similar, but was told that we have limited >> time to execute the DELETE, and that doing it in stages might not be >> possible. > > In cases like this, I have often found that doing the delete in smaller > pieces goes faster, sometimes much faster, than the bigger delete. For some reason it is common for a conversation with a software manager to go like this: Programmer: Let's go with option "A"; it'll be much faster than what we're doing. Manager: We don't have time to do that. We don't have time to be faster? When I've had this conversation, the payback was usually immediate, like it's Wednesday and it'll be faster by Thursday the next day, and we'll get more done by Friday of the same week the new way. But we don't have time. I have had this conversation dozens of times over the years. (I was always "Programmer".) -- Lew Honi soit qui mal y pense. http://upload.wikimedia.org/wikipedia/commons/c/cf/Friz.jpg