libmemcache and pgmemcache...

[Sean Chittenden]

>> Howdy.  Last night I gave a presentation on pgmemcache and libmemcache
>> to the San Francisco PostgreSQL User Group.  For the interested
>> parties, the presentation is available at:
>>
>> http://people.FreeBSD.org/~seanc/pgmemcache/pgmemcache.pdf
>
> I suspect this would be obvious if I had used Postgres more, but you 
> did
> ask for stupid questions at the end, so...

Heh, I just finished answering this question on IRC.  :)

> What exactly are you doing here to glue the two together?  Are you:

> *) replacing Pg disk storage with memcached servers,

Absolutely not

> *) synchronizing all data modifications from Pg to memcached, or

Yes.  I'm currently doing this with replace commands, but am beginning 
to think that it would be better to just issue delete's instead and let 
the client re-add the data.

> *) just caching query results similar to the MySQL query cache?

I do this sometimes when there isn't much else in the way of a choice 
(not that it doesn't work, this works just fine, but is far from 
ideal).  It seems like it's standard practice to have some PHP hacker 
goob things up and do something similar to:

$results = pg_fetch_all(pg_query('SELECT * FROM tbl1, tbl2, tbl3...'));

which is a mess, but, it does have the perk of letting me do something 
like:

$results = $mc->get(md5($sql));
if ($results == null) { // I always change the memcache API to return 
NULL and not false
   $results = pg_fetch_all(pg_query($sql));
   $mc->add(md5($sql), $results);
}

which solves most problems and basically emulates query caching.

> Do queries still go through Pg or go straight to memcached?

Strait to memcached, then to Pg if there is a cache lookup failure.  -sc

-- 
Sean Chittenden