Skip site navigation (1) Skip section navigation (2)

Re: PostgreSQL as a local in-memory cache

From: Pavel Stehule <pavel(dot)stehule(at)gmail(dot)com>
To: "A(dot)M(dot)" <agentm(at)themactionfaction(dot)com>
Cc: postgres performance list <pgsql-performance(at)postgresql(dot)org>
Subject: Re: PostgreSQL as a local in-memory cache
Date: 2010-06-24 21:33:06
Message-ID: AANLkTildXSjE0sNHPm5D_j7QZIGFrE0VdklkmN0xVx0f@mail.gmail.com (view raw or flat)
Thread:
Lists: pgsql-performance
2010/6/24 A.M. <agentm(at)themactionfaction(dot)com>:
>
> On Jun 24, 2010, at 4:01 PM, Pavel Stehule wrote:
>
>> 2010/6/24 Joshua D. Drake <jd(at)commandprompt(dot)com>:
>>> On Thu, 2010-06-24 at 21:14 +0200, Pavel Stehule wrote:
>>>> 2010/6/24 Josh Berkus <josh(at)agliodbs(dot)com>:
>>>>>
>>>>>> And I'm also planning to implement unlogged tables, which have the
>>>>>> same contents for all sessions but are not WAL-logged (and are
>>>>>> truncated on startup).
>>>>
>>>> this is similar MySQL's memory tables. Personally, I don't see any
>>>> practical sense do same work on PostgreSQL now, when memcached exists.
>>>
>>> Because memcache is yet another layer and increases overhead to the
>>> application developers by adding yet another layer to work with. Non
>>> logged tables would rock.
>>
>> I see only one positive point - it can help to people with broken
>> design application with migration to PostgreSQL.
>
> The broken design is being required to work around PostgreSQL's lack of this optimization.
>
>>
>> There are different interesting feature - cached procedure's results
>> like Oracle 11. - it's more general.
>>
>> only idea.
>>
>> For me memory tables are nonsens, but what about memory cached
>> materialised views (maybe periodically refreshed)?
>
> Non-WAL-logged, non-fsynced tables are not equivalent to MySQL "memory tables". Such tables simply contain transient information. One can already make "memory tables" in PostgreSQL by making a tablespace in a tmpfs partition.
>
> I have been eagerly waiting for this feature for six years so that I can write proper queries against ever-changing session data with transactional semantics (which memcached cannot offer). The only restriction I see for these transient data tables is that they cannot be referenced by standard tables using foreign key constraints. Otherwise, these tables behave like any other. That's the benefit.
>

if you remove WAL, then there are MVCC still - you have to do VACUUM,
you have to do ANALYZE, you have to thinking about indexes ...
Processing pipe for simple query is long too. The removing WAL doesn't
do memory database from Postgres. But You have to know best, what do
you do.

Regards

Pavel Stehule

p.s. maybe memcached is too simply for you - there are more NoSQL db

> Cheers,
> M
> --
> Sent via pgsql-performance mailing list (pgsql-performance(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-performance
>

In response to

pgsql-performance by date

Next:From: Josh BerkusDate: 2010-06-24 21:37:35
Subject: Re: PostgreSQL as a local in-memory cache
Previous:From: A.M.Date: 2010-06-24 20:38:45
Subject: Re: PostgreSQL as a local in-memory cache

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group