Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 78D07632DE8 for ; Tue, 15 Jun 2010 14:02:45 -0300 (ADT) Received: from mail.postgresql.org ([200.46.204.86]) by maia.hub.org (mx1.hub.org [200.46.204.251]) (amavisd-maia, port 10024) with ESMTP id 71340-08 for ; Tue, 15 Jun 2010 17:02:34 +0000 (UTC) X-Greylist: delayed 01:00:00.751865 by SQLgrey-1.7.6 Received: from email.noao.edu (email.noao.edu [140.252.1.54]) by mail.postgresql.org (Postfix) with ESMTP id 4E1A662DBE1 for ; Tue, 15 Jun 2010 14:02:34 -0300 (ADT) Received: from weaver.tuc.noao.edu ([140.252.14.8] verified) by email.noao.edu (CommuniGate Pro SMTP 5.2.19) with ESMTPS id 70824627; Tue, 15 Jun 2010 09:02:31 -0700 Received: from weaver.tuc.noao.edu (localhost.localdomain [127.0.0.1]) by weaver.tuc.noao.edu (8.13.8/8.13.8) with ESMTP id o5FG2VZm006942; Tue, 15 Jun 2010 09:02:31 -0700 Message-ID: <4C17A417.2040600@noao.edu> Date: Tue, 15 Jun 2010 09:02:31 -0700 From: Steve Wampler User-Agent: Thunderbird 2.0.0.24 (X11/20100228) MIME-Version: 1.0 To: pgsql-performance@postgresql.org Subject: Re: PostgreSQL as a local in-memory cache References: <87bpbcpabg.fsf@cbbrowne-laptop.afilias-int.info> In-Reply-To: <87bpbcpabg.fsf@cbbrowne-laptop.afilias-int.info> 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=-0.51 tagged_above=-10 required=5 tests=BAYES_05=-0.5, T_RP_MATCHES_RCVD=-0.01 X-Spam-Level: X-Archive-Number: 201006/270 X-Sequence-Number: 39126 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, ... Doesn't PG now support putting both WAL and user table files onto file systems other than the one holding the PG config files and PG 'admin' tables? Wouldn't doing so simplify the above considertably by allowing just the WAL and user tables on the memory-backed file systems? I wouldn't think the performance impact of leaving the rest of the stuff on disk would be that large. Or does losing WAL files mandate a new initdb? -- Steve Wampler -- swampler@noao.edu The gods that smiled on your birth are now laughing out loud.