>>>>> "Shridhar" == Shridhar Daithankar <[EMAIL PROTECTED]> writes:
Shridhar> On Saturday 04 January 2003 03:20 am, you wrote: >> >I am sure, many of you would like to delete this message >> before reading, > hold on. :-) >> >> I'm afraid most posters did not read the message. Those who >> replied >> >> "Why bother?" did not address your challenge: Shridhar> Our challenges may be..;-) Not having threading does reduce some of the freedom we've been having in our work. But then we have ripped the process model a fair bit and we have the freedom of an entirely new process to deal with data streams entering the system and we're experimenting with threading for asynchronous I/O there. However, in general I agree with the spirit of the previous messages in this thread that threading isn't the main issue for PG. One thing that I missed so far in the threading thread. Context switches are (IMHO) far cheaper between threads, because you save TLB flushes. Whether this makes a real difference in a data intensive application, I don't know. I wonder how easy it is to measure the x86 counters to see TLB flushes/misses. In a database system, even if one process dies, I'd be very chary of trusting it. So I am not too swayed by the fact that a process-per-connection gets you better isolation. BTW, many commercial database systems also use per-process models on Unix. However they are very aggressive with connection sharing and reuse - even to the point of reusing the same process for multiple active connections .. maybe at transaction boundaries. Good when a connection is maintained for a long duaration with short-lived transactions separated by fair amouns of time. Moreover, in db2 for instance, the same code base is used for both per-thread and per-process models - in other words, the entire code is MT-safe, and the scheduling mechanism is treated as a policy (Win32 is MT, and some Unices MP). AFAICT though, postgres code, such as perhaps the memory contexts is not MT-safe (of course the bufferpool/shmem accesses are safe). -- Pip-pip Sailesh http://www.cs.berkeley.edu/~sailesh ---------------------------(end of broadcast)--------------------------- TIP 6: Have you searched our list archives? http://archives.postgresql.org