From: | "Shridhar Daithankar" <shridhar_daithankar(at)persistent(dot)co(dot)in> |
---|---|
To: | PostgreSQL Development <pgsql-hackers(at)postgresql(dot)org> |
Subject: | Re: |
Date: | 2003-07-22 15:27:45 |
Message-ID: | 3F1DA549.20040.49B0FD@localhost |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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..
Bye
Shridhar
--
2180, U.S. History question: What 20th Century U.S. President was almost impeached and what office did he later hold?
From | Date | Subject | |
---|---|---|---|
Next Message | Teodor Sigaev | 2003-07-22 16:01:31 | Re: tsearch2 for 7.3.X |
Previous Message | Larry Rosenman | 2003-07-22 15:19:00 | Re: |