Received: from localhost (maia-1.hub.org [200.46.204.191]) by postgresql.org (Postfix) with ESMTP id B121C9FB1CC for ; Tue, 6 Feb 2007 15:11:02 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.191]) (amavisd-new, port 10024) with ESMTP id 00254-08 for ; Tue, 6 Feb 2007 15:10:56 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey-1.7.4 Received: from mir3-fs.mir3.com (mail.mir3.com [65.208.188.100]) by postgresql.org (Postfix) with ESMTP id B75FC9FA385 for ; Tue, 6 Feb 2007 15:10:55 -0400 (AST) Received: mir3-fs.mir3.com 172.16.1.11 from 172.16.2.68 172.16.2.68 via HTTP with MS-WebStorage 6.0.6249 Received: from archimedes.mirlogic.com by mir3-fs.mir3.com; 06 Feb 2007 11:10:53 -0800 Subject: Re: How long should it take to insert 200,000 records? From: Mark Lewis To: Merlin Moncure Cc: Scott Marlowe , Karen Hill , pgsql-performance@postgresql.org In-Reply-To: References: <1170722158.973141.208230@j27g2000cwj.googlegroups.com> <1170778484.5451.97.camel@state.g2switchworks.com> <1170780953.5451.99.camel@state.g2switchworks.com> <1170786686.16656.484.camel@archimedes> Content-Type: text/plain Content-Transfer-Encoding: 7bit Organization: MIR3, Inc. Date: Tue, 06 Feb 2007 11:10:53 -0800 Message-Id: <1170789053.16656.486.camel@archimedes> Mime-Version: 1.0 X-Mailer: Evolution 2.0.2 (2.0.2-27.rhel4.6) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200702/73 X-Sequence-Number: 23127 On Tue, 2007-02-06 at 14:06 -0500, Merlin Moncure wrote: > On 2/6/07, Mark Lewis wrote: > > > actually, I get the stupid award also because RI check to unindexed > > > column is not possible :) (this haunts deletes, not inserts). > > > > Sure it's possible: > > > > CREATE TABLE parent (col1 int4); > > -- insert many millions of rows into parent > > CREATE TABLE child (col1 int4 REFERENCES parent(col1)); > > -- insert many millions of rows into child, very very slowly. > > the database will not allow you to create a RI link out unless the > parent table has a primary key/unique constraint, which the database > backs with an index....and you can't even trick it afterwards by > dropping the constraint. > > it's the other direction, when you cascade forwards when you can have > a problem. this is most common with a delete, but can also happen on > an update of a table's primary key with child tables referencing it. > Hmmm, should check my SQL before hitting send I guess. Well, at least you no longer have to wear the stupid award, Merlin :) -- Mark Lewis