Received: from maia.hub.org (maia-3.hub.org [200.46.204.243]) by mail.postgresql.org (Postfix) with ESMTP id 3FD94B5DC32 for ; Tue, 23 Aug 2011 18:20:22 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.243]) (amavisd-maia, port 10024) with ESMTP id 40989-09 for ; Tue, 23 Aug 2011 21:20:15 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-yw0-f46.google.com (mail-yw0-f46.google.com [209.85.213.46]) by mail.postgresql.org (Postfix) with ESMTP id 4704AB5DC31 for ; Tue, 23 Aug 2011 18:20:15 -0300 (ADT) Received: by ywf7 with SMTP id 7so417580ywf.19 for ; Tue, 23 Aug 2011 14:20:15 -0700 (PDT) Received: by 10.236.9.71 with SMTP id 47mr26850787yhs.30.1314134415079; Tue, 23 Aug 2011 14:20:15 -0700 (PDT) Received: from [10.10.3.129] (71-6-94-66.static-ip.telepacific.net [71.6.94.66]) by mx.google.com with ESMTPS id q25sm478286yhm.20.2011.08.23.14.20.13 (version=SSLv3 cipher=OTHER); Tue, 23 Aug 2011 14:20:14 -0700 (PDT) Subject: Re: skip WAL on COPY patch From: Jeff Davis To: Tom Lane Cc: Steve Singer , PostgreSQL-development Hackers In-Reply-To: <1739.1314126320@sss.pgh.pa.us> References: <4E53E7D5.6030808@ca.afilias.info> <1739.1314126320@sss.pgh.pa.us> Content-Type: text/plain; charset="ISO-8859-1" Date: Tue, 23 Aug 2011 14:20:12 -0700 Message-ID: <1314134412.23681.7.camel@jdavis-ux.asterdata.local> Mime-Version: 1.0 X-Mailer: Evolution 2.28.3 Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-5 required=5 tests=BAYES_00=-1.9 X-Spam-Level: X-Archive-Number: 201108/1076 X-Sequence-Number: 193831 On Tue, 2011-08-23 at 15:05 -0400, Tom Lane wrote: > Steve Singer writes: > > The attached patch adds an option to the COPY command to skip writing > > WAL when the following conditions are all met: > > > 1) The table is empty (zero size on disk) > > 2) The copy command can obtain an access exclusive lock on the table > > with out blocking. > > 3) The WAL isn't needed for replication > > Exposing this as a user-visible option seems a seriously bad idea. In that particular way, I agree. But it might be useful if there were a more general declarative option like "BULKLOAD". We might then use that information for a number of optimizations that make sense for large loads. Regards, Jeff Davis