X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 5ACBCDB5CD for ; Mon, 31 Oct 2005 22:00:18 -0400 (AST) 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 29861-05 for ; Tue, 1 Nov 2005 02:00:14 +0000 (GMT) Received: from cassarossa.samfundet.no (cassarossa.samfundet.no [129.241.93.19]) by svr1.postgresql.org (Postfix) with ESMTP id CF951DB5CB for ; Mon, 31 Oct 2005 22:00:16 -0400 (AST) Received: from trofast.sesse.net ([129.241.93.32]) by cassarossa.samfundet.no with esmtp (Exim 4.50) id 1EWlRh-0002iE-MA; Tue, 01 Nov 2005 03:00:18 +0100 Received: from sesse by trofast.sesse.net with local (Exim 3.36 #1 (Debian)) id 1EWlRq-0001G6-00; Tue, 01 Nov 2005 03:00:26 +0100 Date: Tue, 1 Nov 2005 03:00:26 +0100 From: "Steinar H. Gunderson" To: PostgreSQL Cc: pgsql-performance@postgresql.org Subject: Re: 8.1beta3 performance Message-ID: <20051101020026.GA4707@uio.no> Mail-Followup-To: PostgreSQL , pgsql-performance@postgresql.org References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Operating-System: Linux 2.6.14-rc5 on a x86_64 X-Message-Flag: Outlook? --> http://www.mozilla.org/products/thunderbird/ User-Agent: Mutt/1.5.11 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.009 required=5 tests=[AWL=0.009] X-Spam-Score: 0.009 X-Spam-Level: X-Archive-Number: 200510/488 X-Sequence-Number: 15256 On Mon, Oct 31, 2005 at 05:16:46PM -0600, PostgreSQL wrote: > We're running 8.1beta3 on one server and are having ridiculous performance > issues. This is a 2 cpu Opteron box and both processors are staying at 98 > or 99% utilization processing not-that-complex queries. Prior to the > upgrade, our I/O wait time was about 60% and cpu utilization rarely got very > high, now I/O wait time is at or near zero. It sounds like some query got planned a different way that happened to be really suboptimal -- I've seen really bad queries be quick on earlier versions "by accident" and then not have the same luck on later versions. Could you find out what queries are taking so long (use log_min_duration_statement), and post table definitions and EXPLAIN ANALYZE output here? /* Steinar */ -- Homepage: http://www.sesse.net/