Re: vacuum, performance, and MVCC - Mailing list pgsql-hackers

From Agent M
Subject Re: vacuum, performance, and MVCC
Date
Msg-id f621d7f4c0aed572719bde8db7d8786f@themactionfaction.com
Whole thread Raw
In response to Re: vacuum, performance, and MVCC  (Christopher Kings-Lynne <chris.kings-lynne@calorieking.com>)
Responses Re: vacuum, performance, and MVCC  (Steve Atkins <steve@blighty.com>)
Re: vacuum, performance, and MVCC  (Gavin Sherry <swm@linuxworld.com.au>)
List 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@themactionfaction.com
¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬ ¬



pgsql-hackers by date:

Previous
From: Mark Kirkwood
Date:
Subject: Re: Overhead for stats_command_string et al, take 2
Next
From: Steve Atkins
Date:
Subject: Re: vacuum, performance, and MVCC