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 EE1149DC837 for ; Thu, 22 Dec 2005 22:35:29 -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 13458-03 for ; Thu, 22 Dec 2005 22:35:33 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from rwcrmhc11.comcast.net (rwcrmhc11.comcast.net [216.148.227.151]) by postgresql.org (Postfix) with ESMTP id C9BEF9DCCD7 for ; Thu, 22 Dec 2005 22:35:27 -0400 (AST) Received: from lifebook.aspen (c-66-176-9-173.hsd1.fl.comcast.net[66.176.9.173]) by comcast.net (rwcrmhc11) with ESMTP id <2005122302353001300c5cc7e>; Fri, 23 Dec 2005 02:35:30 +0000 From: Juan Casero To: pgsql-performance@postgresql.org Subject: Re: MySQL is faster than PgSQL but a large margin in Date: Thu, 22 Dec 2005 21:44:32 -0500 User-Agent: KMail/1.8.2 References: <43AAAB58.6050109@logix-tt.com> In-Reply-To: <43AAAB58.6050109@logix-tt.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200512222144.32665.caseroj@comcast.net> X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=1.655 required=5 tests=[AWL=-0.664, DNS_FROM_RFC_POST=1.44, DNS_FROM_RFC_WHOIS=0.879] X-Spam-Score: 1.655 X-Spam-Level: * X-Archive-Number: 200512/574 X-Sequence-Number: 16395 Agreed. I have a 13 million row table that gets a 100,000 new records every week. There are six indexes on this table. Right about the time when it reached the 10 million row mark updating the table with new records started to take many hours if I left the indexes in place during the update. Indeed there was even some suspicion that the indexes were starting to get corrupted during the load. So I decided to fist drop the indexes when I needed to update the table. Now inserting 100,000 records into the table is nearly instantaneous although it does take me a couple of hours to build the indexes anew. This is still big improvement since at one time it was taking almost 12 hours to update the table with the indexes in place. Juan On Thursday 22 December 2005 08:34, Markus Schaber wrote: > Hi, Madison, > Hi, Luke, > > Luke Lonergan wrote: > > Note that indexes will also slow down loading. > > For large loading bunches, it often makes sense to temporarily drop the > indices before the load, and recreate them afterwards, at least, if you > don't have normal users accessing the database concurrently. > > Markus