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 24A699DCD64 for ; Wed, 22 Mar 2006 09:19:09 -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 45243-09 for ; Wed, 22 Mar 2006 09:19:12 -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 B95CB9DD560 for ; Wed, 22 Mar 2006 09:19:06 -0400 (AST) Received: by noel.decibel.org (Postfix, from userid 1001) id 976FD56423; Wed, 22 Mar 2006 07:19:10 -0600 (CST) Received: (hashcash-sendmail, from uid 1001); Wed, 22 Mar 2006 07:19:10 -0600 Date: Wed, 22 Mar 2006 07:19:10 -0600 From: "Jim C. Nasby" To: Simon Riggs Cc: pgsql-performance@postgresql.org Subject: Re: WAL logging of SELECT ... INTO command Message-ID: <20060322131910.GC15742@pervasive.com> References: <20060321122211.GU15742@pervasive.com> <1142973230.24487.501.camel@localhost.localdomain> <20060322124732.GA15742@pervasive.com> <1143032914.24487.632.camel@localhost.localdomain> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1143032914.24487.632.camel@localhost.localdomain> 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:060322:simon@2ndquadrant.com::6wI9gF5ZvYqO8hbh:0000000000000000 0000000000000000000000000EHg X-Hashcash: 1:20:060322:pgsql-performance@postgresql.org::y/TvKZG/HLBsy2XF:00000 0000000000000000000000000vpQ 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/451 X-Sequence-Number: 17888 On Wed, Mar 22, 2006 at 01:08:34PM +0000, Simon Riggs wrote: > On Wed, 2006-03-22 at 06:47 -0600, Jim C. Nasby wrote: > > > Also, why do we log rows for CTAS/SELECT INTO when PITR is in use for > > simple SELECTs (ones that don't call non-deterministic functions)? The > > data should alread be available AFAICS... > > Not sure what you're asking... SELECTs don't produce WAL. Yes, there'd have to be some special kind of WAL entry that specifies what select statement was used in CTAS. > PITR wants all changes. Without PITR we can optimise certain logging > actions. The only change here is that we're creating a new table based on the results of a SELECT. If that SELECT doesn't use anything that's non-deterministic, then the machine doing the recovery should already have all the data it needs, provided that we log the SELECT that was used in the CTAS. -- 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