Received: from localhost (unknown [200.46.204.184]) by postgresql.org (Postfix) with ESMTP id 5DCFA2E3C88 for ; Tue, 5 Feb 2008 12:09:54 -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 17885-03 for ; Tue, 5 Feb 2008 12:09:40 -0400 (AST) Received: from ptb-relay02.plus.net (ptb-relay02.plus.net [212.159.14.213]) by postgresql.org (Postfix) with ESMTP id 8CEB62E0213 for ; Tue, 5 Feb 2008 12:09:40 -0400 (AST) Received: from [84.51.143.99] (helo=server3.office.archonet.com) by ptb-relay02.plus.net with esmtp (Exim) id 1JMQMb-0006k3-UZ; Tue, 05 Feb 2008 16:09:39 +0000 Received: from [192.168.1.36] (dell36.office.archonet.com [192.168.1.36]) by server3.office.archonet.com (Postfix) with ESMTP id B6820274061; Tue, 5 Feb 2008 16:09:35 +0000 (GMT) Message-ID: <47A88A40.5090502@archonet.com> Date: Tue, 05 Feb 2008 16:09:36 +0000 From: Richard Huxton User-Agent: Thunderbird 2.0.0.9 (X11/20071031) MIME-Version: 1.0 To: Matthew CC: pgsql-performance@postgresql.org Subject: Re: Benchmark Data requested 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> <47A8862A.1060205@archonet.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Plusnet-Relay: 033095328f3384cc2dc03c68b593144b X-Virus-Scanned: Maia Mailguard 1.0.1 X-Archive-Number: 200802/43 X-Sequence-Number: 28585 Matthew wrote: > On Tue, 5 Feb 2008, Richard Huxton wrote: >>> Why would you need to lock the table? >> >> Because you're not really writing the WAL, which means you can't let >> anyone else get their data into any of the blocks you are writing >> into. You'd basically want to write the disk blocks then "attach" them >> in some way. > > So what's wrong with "reserving" the space using the WAL, then everyone > else will know. After all, when you write the data to the WAL, you must > have an idea of where it is meant to end up. My suggestion is that you > go through all the motions of writing the data to the WAL, just without > the data bit. Well, now you're looking at page-level locking for the data blocks, or at least something very similar. Not sure what you'd do with indexes though - don't see a simple way of avoiding a large lock on a btree index. If you reserved the space in advance that could work. But you don't know how much to reserve until you've copied it in. You could of course have a set of co-operating processes all bulk-loading while maintaining a table-lock outside of the those. It feels like things are getting complicated then though. -- Richard Huxton Archonet Ltd