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?  ("Jignesh K. Shah" <J.K.Shah@Sun.COM>)
Re: User concurrency thresholding: where do I look?  (David Boreham <david_list@boreham.org>)
Re: User concurrency thresholding: where do I look?  ("Simon Riggs" <simon@2ndquadrant.com>)
Список 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 по дате отправления:

Предыдущее
От: "Jignesh K. Shah"
Дата:
Сообщение: Re: User concurrency thresholding: where do I look?
Следующее
От: "Jignesh K. Shah"
Дата:
Сообщение: Re: User concurrency thresholding: where do I look?