Re: PostgreSQL
Patrick Welche <[email protected]> Thu, 2 Feb 2006 15:37:29 +0000
| Newsgroups | gmane.os.netbsd.current,gmane.os.netbsd.devel.performance,gmane.os.netbsd.devel.general,gmane.os.netbsd.devel.network |
|---|---|
| Message-ID | <[email protected]> |
On Wed, Feb 01, 2006 at 06:58:04PM -0800, Alfred Perlstein wrote: > * Neil Conway <[email protected]> [060201 18:49] wrote: > > On Thu, 2006-02-02 at 00:49 +0000, [email protected] wrote: > > > 1. I was reading somewhere that PostgreSQL was not multithreaded. This can have > > > a significant impact if you have a busy database server. Multicore CPUs > > > designed for executing 10s and 100s of threads simultaneously are just around > > > the corner (Sun's T1 processors). So fine grained threaded applications are the > > > future. > > > > Whether threads or processes are used to implement concurrency does not > > really affect how fine-grained the concurrency is. That is, I don't see > > how using multiple processes and fork() makes an application inherently > > less suitable to multicore servers than an application using threads. > > Ok, I'm on the fence about threads, but the reason why they are a > gain over processes, on multi-core in particular is that the shared > address space means that if you switch between two threads you do > not have to invalidate tlbs or caches during the context switch. > > 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. > > Also, I'm pretty sure that synchronization between threads doesn't > require locked bus cycles, only atomic ops, again another saving. > > But threads aren't always the best thing out there, the code gets > a lot more complicated and crash prone and you wind up sometimes > getting screwed because third party code isn't thread safe... Isn't your last paragraph the reason PostgreSQL sticks to processes? Companies A and B each have databases running from your server. Company A has written flaky procedures which segfault its backends. (some processes disappear) Company B doesn't care - its backends don't share any memory with them, all is well. Cheers, Patrick