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 0A6CF52820 for ; Fri, 3 Jun 2005 20:13:28 -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 86153-10 for ; Fri, 3 Jun 2005 23:13:23 +0000 (GMT) Received: from floppy.pyrenet.fr (news.pyrenet.fr [194.116.145.2]) by svr1.postgresql.org (Postfix) with ESMTP id E9EF852816 for ; Fri, 3 Jun 2005 20:13:22 -0300 (ADT) Received: by floppy.pyrenet.fr (Postfix, from userid 106) id E4B9230952; Sat, 4 Jun 2005 01:09:49 +0200 (MET DST) From: "Morgan" X-Newsgroups: pgsql.performance Subject: Insert slow down on empty database Date: Fri, 3 Jun 2005 16:13:21 -0700 Organization: Hub.Org Networking Services Lines: 31 Message-ID: X-Complaints-To: usenet@news.hub.org X-Priority: 3 X-MSMail-Priority: Normal X-Newsreader: Microsoft Outlook Express 5.50.4942.400 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4942.400 To: pgsql-performance@postgresql.org X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=1.185 tagged_above=0 required=5 tests=PRIORITY_NO_NAME X-Spam-Level: * X-Archive-Number: 200506/79 X-Sequence-Number: 12717 Hi, I am having a problem with inserting a large amount of data with my libpqxx program into an initially empty database. It appears to be the EXACT same problem discussed here: http://archives.postgresql.org/pgsql-bugs/2005-03/msg00183.php In fact my situation is nearly identical, with roughly 5 major tables, with foreign keys between each other. All the tables are being loaded into similtaneously with about 2-3 million rows each. It seems that the problem is caused by the fact that I am using prepared statments, that cause the query planner to choose sequential scans for the foreign key checks due to the table being initially empty. As with the post above, if I dump my connection after about 4000 inserts, and restablish it the inserts speed up by a couple of orders of magnitude and remain realtively constant through the whole insertion. At first I was using straight insert statments, and although they were a bit slower than the prepared statments(after the restablished connection) they never ran into this problem with the database being initially empty. I only changed to the prepared statements because it was suggested in the documentation for advice on bulk data loads =). I can work around this problem, and I am sure somebody is working on fixing this, but I thought it might be good to reaffirm the problem. Thanks, Morgan Kita