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 70E99DB5D5 for ; Mon, 31 Oct 2005 22:06:09 -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 31297-02 for ; Tue, 1 Nov 2005 02:06:04 +0000 (GMT) Received: from mailbox.samurai.com (mailbox.samurai.com [205.207.28.82]) by svr1.postgresql.org (Postfix) with ESMTP id 5E63BDB5CE for ; Mon, 31 Oct 2005 22:06:06 -0400 (AST) Received: from localhost (mailbox.samurai.com [205.207.28.82]) by mailbox.samurai.com (Postfix) with ESMTP id CDCE42399F3; Mon, 31 Oct 2005 21:06:10 -0500 (EST) Received: from mailbox.samurai.com ([205.207.28.82]) by localhost (mailbox.samurai.com [205.207.28.82]) (amavisd-new, port 10024) with LMTP id 74935-02-10; Mon, 31 Oct 2005 21:06:09 -0500 (EST) Received: from [192.168.1.104] (d226-86-55.home.cgocable.net [24.226.86.55]) by mailbox.samurai.com (Postfix) with ESMTP id 469E8239993; Mon, 31 Oct 2005 21:06:09 -0500 (EST) Subject: Re: 8.1beta3 performance From: Neil Conway To: PostgreSQL Cc: pgsql-performance@postgresql.org In-Reply-To: References: Content-Type: text/plain Date: Mon, 31 Oct 2005 21:06:15 -0500 Message-Id: <1130810775.8561.20.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.4.1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at mailbox.samurai.com X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0 required=5 tests=[none] X-Spam-Score: 0 X-Spam-Level: X-Archive-Number: 200510/489 X-Sequence-Number: 15257 On Mon, 2005-31-10 at 17:16 -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. Have you done anything to verify that this is actually a problem with 8.1, and not some other change that was made as part of the upgrade process? For example, if ANALYZE hasn't been re-run, that could cause the plans chosen by the optimizer to be completely different. -Neil