From: | Steve Atkins <steve(at)blighty(dot)com> |
---|---|
To: | PostgreSQL-development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: vacuum, performance, and MVCC |
Date: | 2006-06-23 02:08:48 |
Message-ID: | 3E63D93C-76BD-46A4-97C2-D2E90A9E370D@blighty.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
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
From | Date | Subject | |
---|---|---|---|
Next Message | Qingqing Zhou | 2006-06-23 02:29:20 | Small overhead run time memory trace (Was Re: shall we have a TRACE_MEMORY mode) |
Previous Message | Christopher Kings-Lynne | 2006-06-23 01:56:16 | Re: vacuum, performance, and MVCC |