Received: from maia.hub.org (maia-2.hub.org [200.46.204.251]) by mail.postgresql.org (Postfix) with ESMTP id 5B64E6327BF for ; Thu, 17 Jun 2010 17:13:56 -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 42207-02 for ; Thu, 17 Jun 2010 20:13:48 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from 26.mail-out.ovh.net (26.mail-out.ovh.net [91.121.27.225]) by mail.postgresql.org (Postfix) with SMTP id AB7E263278C for ; Thu, 17 Jun 2010 17:13:48 -0300 (ADT) Received: (qmail 22778 invoked by uid 503); 17 Jun 2010 20:20:20 -0000 Received: from b7.ovh.net (HELO mail407.ha.ovh.net) (213.186.33.57) by 26.mail-out.ovh.net with SMTP; 17 Jun 2010 20:20:20 -0000 Received: from b0.ovh.net (HELO queueout) (213.186.33.50) by b0.ovh.net with SMTP; 17 Jun 2010 22:13:46 +0200 Received: from par69-8-88-161-102-87.fbx.proxad.net (HELO apollo13) (lists%peufeu.com@88.161.102.87) by ns0.ovh.net with SMTP; 17 Jun 2010 22:13:44 +0200 Content-Type: text/plain; charset=utf-8; format=flowed; delsp=yes To: "Dimitri Fontaine" , "Josh Berkus" Cc: "postgres performance list" Subject: Re: PostgreSQL as a local in-memory cache References: <18287446-8677-46d6-a581-c4777f60ebda@40g2000pry.googlegroups.com> <4C1A5B81.8050908@agliodbs.com> Date: Thu, 17 Jun 2010 22:12:25 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit From: "Pierre C" Message-ID: In-Reply-To: User-Agent: Opera Mail/10.10 (Linux) X-Ovh-Tracer-Id: 9365235426892318276 X-Ovh-Remote: 88.161.102.87 (par69-8-88-161-102-87.fbx.proxad.net) X-Ovh-Local: 213.186.33.20 (ns0.ovh.net) X-Spam-Check: DONE|U 0.5/N X-Virus-Scanned: Maia Mailguard 1.0.1 X-Spam-Status: No, hits=-0.5 tagged_above=-10 required=5 tests=BAYES_05=-0.5 X-Spam-Level: X-Archive-Number: 201006/317 X-Sequence-Number: 39173 > Well I guess I'd prefer a per-transaction setting, allowing to bypass > WAL logging and checkpointing. Forcing the backend to care itself for > writing the data I'm not sure is a good thing, but if you say so. Well if the transaction touches a system catalog it better be WAL-logged... A per-table (or per-index) setting makes more sense IMHO. For instance "on recovery, truncate this table" (this was mentioned before). Another option would be "make the table data safe, but on recovery, destroy and rebuild this index" : because on a not so large, often updated table, with often updated indexes, it may not take long to rebuild the indexes, but all those wal-logged index updates do add some overhead.