X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id E50DF9DC9DC for ; Tue, 14 Feb 2006 16:42:45 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 55056-03 for ; Tue, 14 Feb 2006 16:42:46 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from sss.pgh.pa.us (sss.pgh.pa.us [66.207.139.130]) by postgresql.org (Postfix) with ESMTP id B44CF9DC9AC for ; Tue, 14 Feb 2006 16:42:42 -0400 (AST) Received: from sss2.sss.pgh.pa.us (tgl@localhost [127.0.0.1]) by sss.pgh.pa.us (8.13.1/8.13.1) with ESMTP id k1EKgib4022348; Tue, 14 Feb 2006 15:42:44 -0500 (EST) To: Stephen Frost cc: Jay Greenfield , pgsql-performance@postgresql.org Subject: Re: Postgres slower than MS ACCESS In-reply-to: <20060214172022.GC4474@ns.snowman.net> References: <200602141551.k1EFpN6F020512@timberline.ca> <20060214172022.GC4474@ns.snowman.net> Comments: In-reply-to Stephen Frost message dated "Tue, 14 Feb 2006 12:20:22 -0500" Date: Tue, 14 Feb 2006 15:42:44 -0500 Message-ID: <22347.1139949764@sss.pgh.pa.us> From: Tom Lane X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.109 required=5 tests=[AWL=0.109] X-Spam-Score: 0.109 X-Spam-Level: X-Archive-Number: 200602/173 X-Sequence-Number: 17159 Stephen Frost writes: > While it's true that Access almost certainly takes some shortcuts, 24 > minutes for an update across 1.2 millon rows seems an awefully long time > for Postgres. I did some experiments along this line with a trivial table (2 integer columns) of 1.28M rows. I used CVS tip with all parameters at defaults. With no indexes, an UPDATE took about 50 seconds. With one index, it took 628 seconds. It's not hard to believe you could get to Jay's figures with multiple indexes. Looking in the postmaster log, I see I was getting checkpoints every few seconds. Increasing checkpoint_segments to 30 (a factor of 10) brought it down to 355 seconds, and then increasing shared_buffers to 20000 brought it down to 165 sec. Separating WAL and data onto different disks would have helped too, no doubt, but I'm too lazy to try it. regards, tom lane