From: | Greg Stark <gsstark(at)mit(dot)edu> |
---|---|
To: | Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my> |
Cc: | Martijn van Oosterhout <kleptog(at)svana(dot)org>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>, pgsql-general(at)postgresql(dot)org, Greg Stark <gsstark(at)mit(dot)edu> |
Subject: | Re: PREPARE TRANSACTION and webapps |
Date: | 2005-11-17 16:32:03 |
Message-ID: | 87veyrqlq4.fsf@stark.xeocode.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Lincoln Yeoh <lyeoh(at)pop(dot)jaring(dot)my> writes:
> At 06:04 PM 11/16/2005 +0100, Martijn van Oosterhout wrote:
>
> >On Thu, Nov 17, 2005 at 12:29:25AM +0800, Lincoln Yeoh wrote:
> > > My assumption is that pending transactions (e.g. locks and other metainfo)
> > > will take much less memory than database backends.
> >
> >They make take less memory but they take many more resources. Backend
> >don't take locks by themselves, transactions do.
>
> Just curious: how much memory do locks/transactions occupy as a rough
> percentage of backend memory usage? Assume a "typical" active backend (5MB?).
> If it's 50% then sure forget it. But if it's 5% or even 1%...
I'm not sure I agree that 100% overhead is reasonable.
The biggest cost though is in context switching. Instead of having 8 processes
100% busy on 8 processors you have 100 or 1,000 processes mostly idle and
frantically context switching between them.
And in the additional complexity of having to make sure the right database
connection gets reassociated with each application request. The most popular
web server architecture can't even do this since they're in separate
processes; it would necessitate involving yet another process and another
context switch for every bit of data going both directions.
--
greg
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2005-11-17 16:43:22 | Re: strange behavior on 8.1 |
Previous Message | David Rysdam | 2005-11-17 16:31:27 | Re: Very slow queries on 8.1 |