X-Original-To: pgsql-performance-postgresql.org@localhost.postgresql.org Received: from localhost (unknown [200.46.204.144]) by svr1.postgresql.org (Postfix) with ESMTP id 887D1529C0 for ; Fri, 29 Jul 2005 17:30:59 -0300 (ADT) Received: from svr1.postgresql.org ([200.46.204.71]) by localhost (av.hub.org [200.46.204.144]) (amavisd-new, port 10024) with ESMTP id 38606-04 for ; Fri, 29 Jul 2005 20:30:58 +0000 (GMT) Received: from larry.aptalaska.net (larry.aptalaska.net [64.186.96.3]) by svr1.postgresql.org (Postfix) with ESMTP id 05C9F52938 for ; Fri, 29 Jul 2005 17:30:57 -0300 (ADT) Received: from [192.168.98.9] (rdbck-static-287.palmer.mtaonline.net [64.4.232.33]) (authenticated bits=0) by larry.aptalaska.net (8.13.4/8.13.4) with ESMTP id j6TKhsEn019125 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 29 Jul 2005 12:43:55 -0800 Message-ID: <42EA91DC.9030306@aptalaska.net> Date: Fri, 29 Jul 2005 12:30:20 -0800 From: Matthew Schumacher User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en MIME-Version: 1.0 To: Andrew McMillan Cc: pgsql-performance@postgresql.org Subject: Re: Performance problems testing with Spamassassin 3.1.0 References: <42E80C28.2040608@aptalaska.net> <1122532023.25574.1.camel@localhost.localdomain> <42E9749F.6000709@aptalaska.net> <1122616211.5691.340.camel@lamb.mcmillan.net.nz> <42EA6966.8090402@aptalaska.net> <1122668371.5691.352.camel@lamb.mcmillan.net.nz> In-Reply-To: <1122668371.5691.352.camel@lamb.mcmillan.net.nz> X-Enigmail-Version: 0.91.0.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Bayes: Learn: ham X-Scanned-By: MIMEDefang 2.52 on 64.186.96.3 X-Virus-Scanned: by amavisd-new at hub.org X-Spam-Status: No, hits=0 tagged_above=0 required=5 tests= X-Spam-Level: X-Archive-Number: 200507/487 X-Sequence-Number: 13728 Andrew McMillan wrote: > > For the data in question (i.e. bayes scoring) it would seem that not > much would be lost if you did have to restore your data from a day old > backup, so perhaps fsync=false is OK for this particular application. > > Regards, > Andrew McMillan. > Restoring from the previous days backup is plenty exceptable in this application, so is it possible to turn fsync off, but only for this database, or would I need to start another psql instance? schu