Received: from makus.postgresql.org (makus.postgresql.org [98.129.198.125]) by mail.postgresql.org (Postfix) with ESMTP id 049031E15E51 for ; Mon, 27 Feb 2012 11:14:28 -0400 (AST) Received: from smtp.peak6.com ([38.98.137.6]) by makus.postgresql.org with esmtp (Exim 4.72) (envelope-from ) id 1S22HS-0004kN-RF for pgsql-performance@postgresql.org; Mon, 27 Feb 2012 15:14:27 +0000 X-AuditID: 0a64cb1e-b7b86ae000000b8b-0c-4f4b9d4eb683 Message-ID: <4F4B9DC5.70108@peak6.com> Date: Mon, 27 Feb 2012 09:14:13 -0600 From: Shaun Thomas Reply-To: Organization: Peak6 User-Agent: Mozilla/5.0 (X11; Linux i686; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: "Reuven M. Lerner" CC: Subject: Re: Very long deletion time on a 200 GB database References: <4F45FB55.1020600@lerner.co.il> <4F47C6C4.6030102@pinpointresearch.com> <4F4B39EF.2080004@lerner.co.il> <4F4B9721.6050808@peak6.com> <4F4B9A6D.1060102@lerner.co.il> In-Reply-To: <4F4B9A6D.1060102@lerner.co.il> Content-Type: text/plain; charset="UTF-8"; format=flowed content-transfer-encoding: 7bit X-Originating-IP: [10.10.107.46] X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrPIsWRmVeSWpSXmKPExsXCxcQroes319vf4NAicYvrM88xW7x/tJvJ gclj6rMHLB4X9k1jD2CKamC0SczLyy9JLElVSEktTrZVCnB19DZTcMksTs5JzMxNLVJSyEyx VTJTUijISUxOzU3NK7FVSiwoSM1LUbLjUsAANkBlmXkKqXnJ+SmZeem2Sp7B/roWFqaWuoZK dvFYQEITS8aE3ja2glsCFYeWvGBtYJzJ28XIySEhYCLR/+IYO4QtJnHh3no2EJtXQE1i3Yub YDaLgKrEroMtYDVsQPGFu28ygthCArIS+1edYwWx+QWEJfZ9aGLuYuTgEBUIk1jwzhNijKDE yZlPWEBsEQEdid3dL5hAbGagMXMfTgJrFRZwljj1+BzQeC6gkRsYJZ6e6wCbzwnUsP7DAlaI BguJxW8OskPY8hLb385hhrhBTuJOw3M2iPsVJOZcbWeZwCg0C8nuWUjaZyFpX8DIvIpRvLgs MTkj07SgOLekwFCvIDUx20wvL7VkEyMoclNOy+1gnL5U8RCjAAejEg/vwsde/kKsiWXFlbmH GCU4mJVEePWzvf2FeFMSK6tSi/Lji0pzUosPMZoCw2wis5Rocj4wqeSVxBsaG1qaWhqbGRiZ WFooifNy8tj6CwmkA5NDdmpqQWoRTB8TB6dUA2NMlJDBlwex/el1aefKa08Iz7q3Ya7P7MR/ Wm8iFb5xfFL9c3LPz9PvQ5c/u8Y0V2mj/NfMNKl+/aZXx/bLaEV2RqUl7vqwR6Dv7qm531az MV8WaffoCtWM2DHtlvfvKbOf8lw9ryHCPa1J8Qu31qWfSf1ieay39vn5tV5KEQxuetv84PSj VAslluKMREMt5qLiRAASWAZe8gIAAA== X-Pg-Spam-Score: 0.8 (/) X-Archive-Number: 201202/232 X-Sequence-Number: 46404 On 02/27/2012 08:59 AM, Reuven M. Lerner wrote: > From what I understand, the issue isn't one of current disk space, > but rather of how quickly the disk space is being used up. Noted. Just keep in mind that dead rows are not free. In the case of sequence scans, the rows still have to be read from disk and then ignored by the engine. Vacuums also act as sequence scans, so the more data they're reading, the longer that takes. This is especially true on an overloaded system. > I wouldn't be surprised if we end up doing a CLUSTER at some point. > The problem is basically that this machine is in 24/7 operation at > high-speed manufacturing plants, and the best-case scenario is for a > 4-hour maintenance window. The best case scenario is for them to buy a second server. If operation of this app stack really is critical to business, they need to spend the money to keep it working, or they'll end up paying much more for it when it fails. You also said that server has other stuff running on it, and it already has very little memory. That tells me they have no DR node. I'm afraid to even ask how they're doing backups. That one machine is a giant, red, flashing single point of failure. I really hope they understand that. > I've suggested that we might be able to help the situation somewhat > by attaching a portable USB-based hard disk, and adding a new > tablespace that'll let us keep running while we divide up the work > that the disk is doing, but they've made it clear that the current > hardware configuration cannot and will not change. Period. And that's it, then. You have yourself a bad client. If it were me, I'd get through this contract and never do business with them again. They have a system that's basically 100% guaranteed to fail some time in the future (and yet is critical for operation!) and are putting Band-Aids on it. I think there's a parable somewhere about eggs and baskets, but I can't recall it at this moment. ;) -- Shaun Thomas OptionsHouse | 141 W. Jackson Blvd. | Suite 500 | Chicago IL, 60604 312-444-8534 sthomas@peak6.com ______________________________________________ See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email