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 73B5B52A0D for ; Tue, 19 Jul 2005 17:08:45 -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 50859-04 for ; Tue, 19 Jul 2005 20:08:44 +0000 (GMT) Received: from wproxy.gmail.com (wproxy.gmail.com [64.233.184.201]) by svr1.postgresql.org (Postfix) with ESMTP id ED0A952A04 for ; Tue, 19 Jul 2005 17:08:43 -0300 (ADT) Received: by wproxy.gmail.com with SMTP id i3so1303188wra for ; Tue, 19 Jul 2005 13:08:45 -0700 (PDT) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=PIWUxpRgnErhtfEfneFNyuHwwUInsGpzJUt58vqaIr3TuY0/US0bv11mOoma8GjzBfF7DIZewc5yy7ixildx32uR0G54l3x5MmF0ibGufZLxo/g/hDopyfe1ZLbUeUp78DiDzWVxF9VRFEzZxp8ePAhZNJg9/ufOHD7YNjMtRTM= Received: by 10.54.130.10 with SMTP id c10mr877747wrd; Tue, 19 Jul 2005 13:08:11 -0700 (PDT) Received: by 10.54.150.2 with HTTP; Tue, 19 Jul 2005 13:08:11 -0700 (PDT) Message-ID: <1efd553a0507191308219a098b@mail.gmail.com> Date: Tue, 19 Jul 2005 16:08:11 -0400 From: Oliver Crosby Reply-To: Oliver Crosby To: Kevin Grittner Subject: Re: Looking for tips Cc: jd@commandprompt.com, pgsql-performance@postgresql.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0.073 tagged_above=0 required=5 tests=AWL, RCVD_BY_IP X-Spam-Level: X-Archive-Number: 200507/321 X-Sequence-Number: 13562 > We had low resource utilization and poor throughput on inserts of > thousands of rows within a single database transaction. There were a > lot of configuration parameters we changed, but the one which helped the > most was wal_buffers -- we wound up setting it to 1000. This may be > higher than it needs to be, but when we got to something which ran well, > we stopped tinkering. The default value clearly caused a bottleneck. I just tried wal_buffers =3D 1000, sort_mem at 10% and effective_cache_size at 75%. The performance refuses to budge.. I guess that's as good as it'll go?