Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 9E718632E20 for ; Tue, 15 Jun 2010 14:12:54 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.29]) (amavisd-maia, port 10024) with ESMTP id 38360-05 for ; Tue, 15 Jun 2010 17:12:46 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from mail-ww0-f46.google.com (mail-ww0-f46.google.com [74.125.82.46]) by mail.postgresql.org (Postfix) with ESMTP id 060ED632D9B for ; Tue, 15 Jun 2010 14:12:45 -0300 (ADT) Received: by wwb18 with SMTP id 18so4987082wwb.19 for ; Tue, 15 Jun 2010 10:12:43 -0700 (PDT) Received: by 10.216.180.198 with SMTP id j48mr3851374wem.108.1276621963367; Tue, 15 Jun 2010 10:12:43 -0700 (PDT) Received: from Craig-Jamess-MacBook-Pro.local (wsip-70-167-124-126.sd.sd.cox.net [70.167.124.126]) by mx.google.com with ESMTPS id d50sm1892592wej.38.2010.06.15.10.12.40 (version=SSLv3 cipher=RC4-MD5); Tue, 15 Jun 2010 10:12:42 -0700 (PDT) Message-ID: <4C17B486.8090502@emolecules.com> Date: Tue, 15 Jun 2010 10:12:38 -0700 From: Craig James User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 MIME-Version: 1.0 To: Steve Wampler , pgsql-performance@postgresql.org Subject: Re: PostgreSQL as a local in-memory cache References: <87bpbcpabg.fsf@cbbrowne-laptop.afilias-int.info> <4C17A417.2040600@noao.edu> In-Reply-To: <4C17A417.2040600@noao.edu> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-1.9 tagged_above=-10 required=5 tests=BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001 X-Spam-Level: X-Archive-Number: 201006/271 X-Sequence-Number: 39127 [oops, didn't hit "reply to list" first time, resending...] On 6/15/10 9:02 AM, Steve Wampler wrote: > Chris Browne wrote: >> "jgardner@jonathangardner.net" writes: >>> My question is how can I configure the database to run as quickly as >>> possible if I don't care about data consistency or durability? That >>> is, the data is updated so often and it can be reproduced fairly >>> rapidly so that if there is a server crash or random particles from >>> space mess up memory we'd just restart the machine and move on. >> >> For such a scenario, I'd suggest you: >> >> - Set up a filesystem that is memory-backed. On Linux, RamFS or TmpFS >> are reasonable options for this. >> >> - The complication would be that your "restart the machine and move >> on" needs to consist of quite a few steps: >> >> - recreating the filesystem >> - fixing permissions as needed >> - running initdb to set up new PG instance >> - automating any needful fiddling with postgresql.conf, pg_hba.conf >> - starting up that PG instance >> - creating users, databases, schemas, ... How about this: Set up a database entirely on a RAM disk, then install a WAL-logging warm standby. If the production computer goes down, you bring the warm standby online, shut it down, and use tar(1) to recreate the database on the production server when you bring it back online. You have speed and you have near-100% backup. Craig