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

Re: memcached and PostgreSQL

From: Sean Chittenden <sean(at)chittenden(dot)org>
To: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>
Cc: Pierre-Frédéric Caillaud <lists(at)boutiquenumerique(dot)com>,pgsql-performance(at)postgresql(dot)org
Subject: Re: memcached and PostgreSQL
Date: 2004-11-23 22:20:34
Message-ID: E4CFD3F7-3D9D-11D9-866D-000A95C705DC@chittenden.org (view raw or flat)
Thread:
Lists: pgsql-performance
> My point was that there are two failure cases --- one where the cache 
> is
> slightly out of date compared to the db server --- these are cases 
> where
> the cache update is slightly before/after the commit.

I was thinking about this and ways to minimize this even further.  Have 
memcache clients add data and have a policy to have the database only 
delete data.  This sets the database up as the bottleneck again, but 
then you have a degree of transactionality that couldn't be previously 
achieved with the database issuing replace commands.  For example:

1) client checks the cache for data and gets a cache lookup failure
2) client beings transaction
3) client SELECTs data from the database
4) client adds the key to the cache
5) client commits transaction

This assumes that the client won't rollback or have a transaction 
failure.  Again, in 50M transactions, I doubt one of them would fail 
(sure, it's possible, but that's a symptom of bigger problems: 
memcached isn't an RDBMS).

The update case being:

1) client begins transaction
2) client updates data
3) database deletes record from memcache
4) client commits transaction
5) client adds data to memcache

> The second is
> where the cache update happens and the commit later fails, or the 
> commit
> happens and the cache update never happens.

Having pgmemcache delete, not replace data addresses this second issue. 
  -sc

-- 
Sean Chittenden


In response to

Responses

pgsql-performance by date

Next:From: Mike MascariDate: 2004-11-24 02:04:15
Subject: Re: Slow execution time when querying view with WHERE clause
Previous:From: Dave PageDate: 2004-11-23 20:12:21
Subject: Re: scalability issues on win32

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