X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id DB01D53528 for ; Wed, 20 Apr 2005 17:44:04 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 39026-06 for ; Wed, 20 Apr 2005 20:43:56 +0000 (GMT) Received: from ylpvm15.prodigy.net (ylpvm15-ext.prodigy.net [207.115.57.46]) by svr1.postgresql.org (Postfix) with ESMTP id 33A8A5372D for ; Wed, 20 Apr 2005 17:43:55 -0300 (ADT) Received: from pimout7-ext.prodigy.net (pimout7-ext.prodigy.net [207.115.63.58]) by ylpvm15.prodigy.net (8.12.10 outbound/8.12.10) with ESMTP id j3KKe3NA008581 for ; Wed, 20 Apr 2005 16:40:04 -0400 X-ORBL: [69.235.29.228] Received: from [192.168.1.103] (adsl-69-235-29-228.dsl.irvnca.pacbell.net [69.235.29.228]) by pimout7-ext.prodigy.net (8.12.10 milter /8.12.10) with ESMTP id j3KKhp8L020712 for ; Wed, 20 Apr 2005 16:43:56 -0400 Mime-Version: 1.0 (Apple Message framework v622) In-Reply-To: <1114025818.66326.34.camel@home> References: <6f4567d4e64297b356e2d71ec392cdae@richardplotkin.com> <1114025818.66326.34.camel@home> Content-Type: text/plain; charset=US-ASCII; format=flowed Message-Id: <73a30faf07358bdb7935f97f50dd1189@richardplotkin.com> Content-Transfer-Encoding: 7bit From: Richard Plotkin Subject: Re: Disk filling, CPU filling, renegade inserts and deletes? Date: Wed, 20 Apr 2005 13:43:50 -0700 To: pgsql-performance@postgresql.org X-Mailer: Apple Mail (2.622) X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests= X-Spam-Level: X-Archive-Number: 200504/534 X-Sequence-Number: 11931 As a follow-up, I've found a function that used the following code: CREATE TEMPORARY TABLE results (nOrder integer, page_id integer, name text) WITHOUT OIDS ON COMMIT DROP; I would assume that the "WITHOUT OIDS" would be part of the source of the problem, so I've commented it out. On Apr 20, 2005, at 12:36 PM, Rod Taylor wrote: >> I'm having a pretty serious problem with postgresql's performance. >> Currently, I have a cron task that is set to restart and vacuumdb -faz >> every six hours. If that doesn't happen, the disk goes from 10% full >> to 95% full within 2 days (and it's a 90GB disk...with the database >> being a 2MB download after dump), and the CPU goes from running at >> around a 2% load to a 99+% load right away (the stats look like a >> square wave). > > Are you running frequent queries which use temporary tables? > > > -- >