Re: PostgreSQL
Alfred Perlstein <[email protected]> Wed, 1 Feb 2006 19:43:20 -0800
| Newsgroups | gmane.os.netbsd.devel.performance |
|---|---|
| Message-ID | <[email protected]> |
* [email protected] <[email protected]> [060201 19:16] wrote: > On Wed, Feb 01, 2006 at 06:58:04PM -0800, Alfred Perlstein wrote: > > > > Also, thread to thread synchronization is somewhat faster than process > > to process synchronization. Honestly, the default thread synchronization > > primitives typically blow the inter-process ones out of the water, > > although there are some OS's and libraries that provide relatively > > fast/cheap inter process syntonization. > > It depends *very* strongly which mechanisms you use. If all you need and > want is a block mutex, you ultimately have to call the kernel for > synchronistation anyway -- both in forking and 1:1 threading. No, there's a couple of tricks to get around that just using locked cycles. > Databases are different from many other applications in that they have a > wide range of possible lock points and it is not easy to even guess > where contention might be. For example, the discussed Postgres is pretty > reader lock free due to the Multi Version Commit system. MySQL is > different in that regard. Regardless, cheaper locks are better, right? > > Also, I'm pretty sure that synchronization between threads doesn't > > require locked bus cycles, only atomic ops, again another saving. > > Ahem. How do you expect two threads on different CPUs to synchronise > correctly if no locked bus cycles are involved? It is important to > distinguish atomic operation and atomic bus locked operations after all > :-) Ugh, you're right, userland threads in my mind. :( Thanks. -- - Alfred Perlstein