Re: Anyone working on better transaction locking?

Greg Stark <gsstark(at)mit(dot)edu> writes:
> However even if you reuse existing database connections, you nonetheless are
> still context switching between hundreds or potentially thousands of threads
> of execution. The lighter-weight that context switch is, the faster it'll be
> able to do that.

> It's tricky to evaluate the cost of the context switches because a big part of
> the cost is simply the tlb flushes. Not only does a process context switch
> involve swapping in memory maps and other housekeeping, but all future memory
> accesses like the data copies that an OLTP system spends most of its time
> doing are slowed down.

So? You're going to be paying those costs *anyway*, because most of the
process context swaps will be between the application server and the
database. A process swap is a process swap, and if you are doing only
very short transactions, few of those swaps will be between database
contexts --- app to database to app will be the common pattern. Unless
you'd like to integrate the client into the same address space as the
database, I do not see that there's an argument here that says multiple
threads in the database will be markedly faster than multiple processes.

regards, tom lane