Re: - Mailing list pgsql-hackers
From | Shridhar Daithankar |
---|---|
Subject | Re: |
Date | |
Msg-id | 3F1DA549.20040.49B0FD@localhost Whole thread Raw |
In response to | ... (Peter Eisentraut <peter_e@gmx.net>) |
Responses |
Re:
Re: |
List | pgsql-hackers |
On 22 Jul 2003 at 16:55, Peter Eisentraut wrote: > I've been thinking some about how exactly to provide the new option of > thread-safe clients (libpq, ecpg). Let me state the following goals: > > a. Thread-safeness, where it makes a difference, is generally thought to > be a performance hit, so the user needs to have a choice to use > thread-safe libraries or not. On linux and freeBSD, that is not an issue. I can attest that from my experiments with a webserver. Thread function calls often time less than or of the order of 1us even with CPU capped. I would really like to know for what platforms, locking mutex while selecting from connection list or some such object, is going to be such a great performance hit. Performance degradation in threaded programs comes from contentions. It goes for frequency of contention and number of threads fighting over it. I doubt any threaded ecpg program would reach that level of contention anytime. If a lock canbe obtained/released in less than 10us and subsequent database query is going to take at least a ms, IMO that performance degradation is not worth that much trouble. But that is for linux and freeBSD. What other platforms have serious thread issues? > Clearly, a thread-safe ecpg library is always going to be significantly > different from the "normal" one, with all the mutex things that get pulled > in, so it seems reasonable to always offer a libecpg_r alongside the > libecpg. I would say, it should be thread-safe by default. No point polluting possible linkages. I repeat what I have said earlier. If there are two libraries A using libecpg_r and B, using libecpg, then program linking against both of them is going to have tough time living with symbol conflicts. I suppose problem will be reproducible even under freeBSD if you try to create a postgresql function in C which uses threads. Link the library against libc_r and link postgresql against libc. It would run into problems. I am just stating my experiences.I might have missed solution to this problem. But overall I like GNU libc approach of everything thread safe by default. If thread performance is an issue, then it should be improved. Not worked around with two libraries. Just a thought.. ByeShridhar -- 2180, U.S. History question: What 20th Century U.S. President was almost impeached and what office did he later hold?
pgsql-hackers by date: