Ivan Voras wrote:
On 23 November 2010 10:35, David Xu wrote:
Ivan Voras wrote:
and the overall behaviour is similar - the processes spend a lot of time
in "sbwait" and "ksem" states.
Strange, the POSIX semaphore in head branch does not use ksem, it is
based on umtx, there is no limit on PO
On 23 November 2010 10:35, David Xu wrote:
> Ivan Voras wrote:
>> and the overall behaviour is similar - the processes spend a lot of time
>> in "sbwait" and "ksem" states.
>>
> Strange, the POSIX semaphore in head branch does not use ksem, it is
> based on umtx, there is no limit on POSIX semaph
Ivan Voras wrote:
On 11/23/10 01:26, Ivan Voras wrote:
On 11/22/10 17:37, David Xu wrote:
Mark Felder wrote:
I recommend posting this on the Postgres performance list, too.
Regards,
Mark
I think if PostgreSQL uses semaphore for inter-process locking,
it might be a good idea to use POSI
On 11/23/10 01:26, Ivan Voras wrote:
On 11/22/10 17:37, David Xu wrote:
Mark Felder wrote:
I recommend posting this on the Postgres performance list, too.
Regards,
Mark
I think if PostgreSQL uses semaphore for inter-process locking,
it might be a good idea to use POSIX semaphore exits i
On 11/22/10 17:37, David Xu wrote:
Mark Felder wrote:
I recommend posting this on the Postgres performance list, too.
Regards,
Mark
I think if PostgreSQL uses semaphore for inter-process locking,
it might be a good idea to use POSIX semaphore exits in our head
branch, the new POSIX semap
Mark Felder wrote:
I recommend posting this on the Postgres performance list, too.
Regards,
Mark
I think if PostgreSQL uses semaphore for inter-process locking,
it might be a good idea to use POSIX semaphore exits in our head
branch, the new POSIX semaphore implementation now supports
pro
