On Jun 22, 2006, at 6:56 PM, Agent M wrote:
>
> On Jun 22, 2006, at 9:56 PM, Christopher Kings-Lynne wrote:
>
>>> The example is a very active web site, the flow is this:
>>> query for session information
>>> process HTTP request
>>> update session information
>>> This happens for EVERY http request. Chances are that you won't have
>>> concurrent requests for the same row, but you may have well over
>>> 100 HTTP
>>> server processes/threads answering queries in your web server farm.
>>
>> You're crazy :) Use memcache, not the DB :)
>
> Still, the database is the one central location that the apaches
> can connect too- postgres already has a lot of application platform
> features- locking synchronization, asynchronous notifications,
> arbitrary pl code.
>
> Personally, I think that a special non-MVCC table type could be
> created- the catalogs are similarly flat. What I envision is a
> table type that can only be accessed "outside" transactions (like
> AutoCommit mode)- this is already possible to implement in plperl
> for a single session. It would be more efficient to have something
> like a global temp table hanging around...
>
Have you seen pgmemcache? It allows you to access a memcached
instance from within postgresql - which makes many of the problems
with using a separate caching / storage layer go away, or at least
get far easier to deal with.
Cheers, Steve
