From: | Agent M <agentm(at)themactionfaction(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: vacuum, performance, and MVCC |
Date: | 2006-06-23 01:56:12 |
Message-ID: | f621d7f4c0aed572719bde8db7d8786f@themactionfaction.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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...
Just some random ideas...
-M
¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬
AgentM
agentm(at)themactionfaction(dot)com
¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬
From | Date | Subject | |
---|---|---|---|
Next Message | Christopher Kings-Lynne | 2006-06-23 01:56:16 | Re: vacuum, performance, and MVCC |
Previous Message | Mark Kirkwood | 2006-06-23 01:51:38 | Re: Overhead for stats_command_string et al, take 2 |