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 96725D8E84 for ; Fri, 23 Sep 2005 08:19:48 -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 32025-07 for ; Fri, 23 Sep 2005 11:19:45 +0000 (GMT) Received: from olive.qinip.net (olive.qinip.net [62.100.30.40]) by svr1.postgresql.org (Postfix) with ESMTP id BF9B9D8E7B for ; Fri, 23 Sep 2005 08:19:45 -0300 (ADT) Received: from [10.0.0.2] (h8441139206.dsl.speedlinq.nl [84.41.139.206]) by olive.qinip.net (Postfix) with ESMTP id 3281218167; Fri, 23 Sep 2005 13:19:44 +0200 (MEST) Message-ID: <4333E4DB.4020206@tweakers.net> Date: Fri, 23 Sep 2005 13:19:55 +0200 From: Arjen van der Meijden User-Agent: Mozilla Thunderbird 1.0RC1 (Windows/20041201) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Stone Cc: pgsql-performance@postgresql.org Subject: Re: How to determine cause of performance problem? References: <1127458167.2475.105.camel@Panoramix> <20050923095517.GW14918@mathom.us> <1127470875.3524.17.camel@Panoramix> <20050923110500.GX14918@mathom.us> In-Reply-To: <20050923110500.GX14918@mathom.us> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0 required=5 tests=[none] X-Spam-Level: X-Archive-Number: 200509/284 X-Sequence-Number: 14592 On 23-9-2005 13:05, Michael Stone wrote: > On Fri, Sep 23, 2005 at 12:21:15PM +0200, Joost Kraaijeveld wrote: > > Ok, that's great, but you didn't respond to the suggestion of using COPY > INTO instead of INSERT. > >> But I have no clue where to begin with determining the bottleneck (it >> even may be a normal performance for all I know: I have no experience >> with converting such (large) database). >> >> Any suggestions? > > > Respond to the first suggestion? Another suggestion: How many indexes and constraints are on the new table? Drop all of them and recreate them once the table is filled. Of course that only works if you know your data will be ok (which is normal for imports of already conforming data like database dumps of existing tables). This will give major performance improvements, if you have indexes and such on the new table. Best regards, Arjen