A C client for memcached
sean at chittenden.org
Thu Oct 28 16:18:55 PDT 2004
> Are your memcached functions for PostgreSQL anywhere near portable?
> I'd love
> to play with them.
It's on my list of things to do. I have my own half-baked programming
language and in my PostgreSQL code, I used the string handling from my
language instead of C's routines. Once I decouple them, I will most
certainly open them up. Essentially what it does is, if one doesn't
exist, it establishes a connection. On updates it fires off a replace
to the appropriate server. On delete, it issues a delete. I don't do
anything on INSERTs that way it only gets loaded into the cluster when
the data is actually read by the client.
I'm finding that on tables that pertain to signups, I'm incuring an
unnecessary hit to the database. Once a user signs up, they're going
to proceed login 99% of the time... why not preempt the lookup when you
know it's coming? Right now I handle caching on the login page, but
I'm finding that I might as well throw the object into the cache on
signup. Anyway, to handle that case, I'm likely going to create an
INSERT trigger/routine, but haven't done so yet. Once I do though,
I'll consider it a nicely rounded out PostgreSQL library that I'll
likely want to post on pgfoundry or have included in the base install
as a contrib module. *shrug*
I'm dying for some COMMIT triggers, 'cause as things stand, I've set
these up as AFTER tiggers, but bogus and I'm pre-caching data before
the transaction is committed. A user could signup and *not* complete
the transaction... but would log in. Thankfully I've only had one
instance of this in the wild and my code removes any keys if the
transaction isn't successful. It'd be nice to have a trigger list for
on commit and on rollback explicitly for this reason.
Don't hesitate to nag me, if you don't see me making progress on it.
More information about the memcached