Received: from maia.hub.org (maia-5.hub.org [200.46.204.29]) by mail.postgresql.org (Postfix) with ESMTP id 4847F6322D5 for ; Thu, 24 Jun 2010 18:37:48 -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 27463-04 for ; Thu, 24 Jun 2010 21:37:40 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from glacier.frostconsultingllc.com (glacier.frostconsultingllc.com [69.36.227.170]) by mail.postgresql.org (Postfix) with ESMTP id C65D5632277 for ; Thu, 24 Jun 2010 18:37:40 -0300 (ADT) Received: from dsl081-245-111.sfo1.dsl.speakeasy.net ([64.81.245.111] helo=Sidney-Stratton.local) by glacier.frostconsultingllc.com with esmtpsa (TLSv1:CAMELLIA256-SHA:256) (Exim 4.69) (envelope-from ) id 1ORu75-0004j3-Da for pgsql-performance@postgresql.org; Thu, 24 Jun 2010 14:37:38 -0700 Message-ID: <4C23D01F.5060607@agliodbs.com> Date: Thu, 24 Jun 2010 14:37:35 -0700 From: Josh Berkus User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 MIME-Version: 1.0 To: 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> <4C1BDD40.9030806@agliodbs.com> <4C23AA6C.60505@agliodbs.com> In-Reply-To: Content-Type: text/plain; charset=UTF-8 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 X-Spam-Level: X-Archive-Number: 201006/447 X-Sequence-Number: 39303 > this is similar MySQL's memory tables. Personally, I don't see any > practical sense do same work on PostgreSQL now, when memcached exists. Thing is, if you only have one table (say, a sessions table) which you don't want logged, you don't necessarily want to fire up a 2nd software application just for that. Plus, recent testing seems to show that with no logging, memcached isn't really faster than PG. Also, like for asynch_commit, this is something where users are currently turning off fsync. Any option where we can present users with controlled, predictable data loss instead of random corruption is a good one. > Much more important is smarter cache controlling then we have now - > maybe with priorities for some tables and some operations > (applications) - sometimes we don't need use cache for extra large > scans. Well, that would be good *too*. You working on it? ;-) -- -- Josh Berkus PostgreSQL Experts Inc. http://www.pgexperts.com