X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (av.hub.org [200.46.204.144]) by postgresql.org (Postfix) with ESMTP id 37F649DC804 for ; Fri, 24 Mar 2006 09:01:20 -0400 (AST) Received: from postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 03920-07 for ; Fri, 24 Mar 2006 09:01:23 -0400 (AST) X-Greylist: from auto-whitelisted by SQLgrey- Received: from noel.decibel.org (noel.decibel.org [67.100.216.10]) by postgresql.org (Postfix) with ESMTP id D90969DC897 for ; Fri, 24 Mar 2006 09:01:17 -0400 (AST) Received: by noel.decibel.org (Postfix, from userid 1001) id E1B6356443; Fri, 24 Mar 2006 07:01:21 -0600 (CST) Received: (hashcash-sendmail, from uid 1001); Fri, 24 Mar 2006 07:01:21 -0600 Date: Fri, 24 Mar 2006 07:01:21 -0600 From: "Jim C. Nasby" To: Qingqing Zhou , pgsql-performance@postgresql.org Subject: Re: WAL logging of SELECT ... INTO command Message-ID: <20060324130121.GE90527@pervasive.com> References: <20060321122211.GU15742@pervasive.com> <1142973230.24487.501.camel@localhost.localdomain> <20060324100731.GO90527@pervasive.com> <20060324123902.GA14217@surnet.cl> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20060324123902.GA14217@surnet.cl> X-Operating-System: FreeBSD 6.0-RELEASE-p4 amd64 X-Distributed: Join the Effort! http://www.distributed.net User-Agent: Mutt/1.5.11 X-Hashcash: 1:20:060324:zhouqq@cs.toronto.edu::Ku2iJFtn6JR+IPiQ:0000000000000000 0000000000000000000000002Ddt X-Hashcash: 1:20:060324:pgsql-performance@postgresql.org::f3v8uYgmt6ZvBdNa:00000 0000000000000000000000001Qwt X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, score=0.108 required=5 tests=[AWL=0.108] X-Spam-Score: 0.108 X-Spam-Level: X-Archive-Number: 200603/491 X-Sequence-Number: 17928 On Fri, Mar 24, 2006 at 08:39:02AM -0400, Alvaro Herrera wrote: > Jim C. Nasby wrote: > > > Why would the content of the old_table be unreliable? If we've replayed > > logs up to the point of the CTAS then any data that would be visible to > > the CTAS should be fine, no? > > > > Though, the way Tom put it in one of his replies it sounds like WAL > > doesn't do any kind of statement logging, only data logging. If that's > > the case I'm not sure that the CTAS would actually get replayed. But I > > suspect I'm just misunderstanding... > > The CTAS doesn't get logged (nor replayed obviously). What happens is > that the involved files are fsync'ed before transaction commit, AFAIR. Ahh, yes, that sounds right. Might be a nice gain to be had if there was some way to log the statement, but I suspect getting WAL to support that would be extremely non-trivial. -- Jim C. Nasby, Sr. Engineering Consultant jnasby@pervasive.com Pervasive Software http://pervasive.com work: 512-231-6117 vcard: http://jim.nasby.net/pervasive.vcf cell: 512-569-9461