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
---------------------------(end of broadcast)---------------------------
TIP 9: In versions below 8.0, the planner will ignore your desire to
choose an index scan if your joining column's datatypes do not
match
