Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 922F42E43E9 for ; Tue, 5 Feb 2008 12:20:17 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (mx1.hub.org [200.46.204.184]) (amavisd-maia, port 10024) with ESMTP id 66555-01-4 for ; Tue, 5 Feb 2008 12:20:01 -0400 (AST) Received: from brmea-mail-2.sun.com (brmea-mail-2.Sun.COM [192.18.98.43]) by postgresql.org (Postfix) with ESMTP id E65702E4134 for ; Tue, 5 Feb 2008 12:18:36 -0400 (AST) Received: from fe-amer-09.sun.com ([192.18.109.79]) by brmea-mail-2.sun.com (8.13.6+Sun/8.12.9) with ESMTP id m15GIZPS005497 for ; Tue, 5 Feb 2008 16:18:35 GMT Received: from conversion-daemon.mail-amer.sun.com by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JVR00M01VZFWR00@mail-amer.sun.com> (original mail from J.K.Shah@Sun.COM) for pgsql-performance@postgresql.org; Tue, 05 Feb 2008 09:18:35 -0700 (MST) Received: from [129.148.168.2] by mail-amer.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JVR007ZMXALE950@mail-amer.sun.com>; Tue, 05 Feb 2008 09:18:22 -0700 (MST) Date: Tue, 05 Feb 2008 11:14:39 -0500 From: "Jignesh K. Shah" Subject: Re: Benchmark Data requested In-reply-to: <1202225207.4252.718.camel@ebony.site> To: Simon Riggs Cc: Richard Huxton , Dimitri Fontaine , pgsql-performance@postgresql.org, Greg Smith Message-id: <47A88B6F.8070905@sun.com> Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=ISO-8859-1 Content-transfer-encoding: 7BIT References: <1202150236.4252.521.camel@ebony.site> <47A797E5.4000507@sun.com> <200802051506.51581.dfontaine@hi-media.com> <1202221496.4252.680.camel@ebony.site> <47A87618.1090203@archonet.com> <1202223268.4252.707.camel@ebony.site> <47A87B2E.7050205@archonet.com> <1202225207.4252.718.camel@ebony.site> User-Agent: Thunderbird 2.0.0.4 (X11/20070622) X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200802/44 X-Sequence-Number: 28586 One of the problems with "Empty Table optimization" is that if there are indexes created then it is considered as no longer empty. Commercial databases have options like "IRRECOVERABLE" clause along with DISK PARTITIONS and CPU partitions for their bulk loaders. So one option turns off logging, disk partitions create multiple processes to read various lines/blocks from input file and other various blocks to clean up the bufferpools to disk and CPU partitions to process the various blocks/lines read for their format and put the rows in bufferpool if successful. Regards, Jignesh Simon Riggs wrote: > On Tue, 2008-02-05 at 15:05 +0000, Richard Huxton wrote: > > >>> Only by locking the table, which serializes access, which then slows you >>> down or at least restricts other options. Plus if you use pg_loader then >>> you'll find only the first few rows optimized and all the rest not. >>> >> Hmm - the table-locking requirement is true enough, but why would >> pg_loader cause problems after the first few rows? >> > > It runs a stream of COPY statements, so only first would be optimized > with the "empty table optimization". > >