Re: User concurrency thresholding: where do I look?
От | Tom Lane |
---|---|
Тема | Re: User concurrency thresholding: where do I look? |
Дата | |
Msg-id | 15343.1184965054@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | Re: User concurrency thresholding: where do I look? ("Jignesh K. Shah" <J.K.Shah@Sun.COM>) |
Ответы |
Re: User concurrency thresholding: where do I look?
Re: User concurrency thresholding: where do I look? Re: User concurrency thresholding: where do I look? |
Список | pgsql-performance |
"Jignesh K. Shah" <J.K.Shah@Sun.COM> writes: > What its saying is that there are holds/waits in trying to get locks > which are locked at Solaris user library levels called from the > postgresql functions: > For example both the following functions are hitting on the same mutex > lock 0x10059e280 in Solaris Library call: > postgres`AllocSetDelete+0x98 > postgres`AllocSetAlloc+0x1c4 That's a perfect example of the sort of useless overhead that I was complaining of just now in pgsql-patches. Having malloc/free use an internal mutex is necessary in multi-threaded programs, but the backend isn't multi-threaded. And yet, apparently you can't turn that off in Solaris. (Fortunately, the palloc layer is probably insulating us from malloc's performance enough that this isn't a huge deal. But it's annoying.) regards, tom lane
В списке pgsql-performance по дате отправления: