From: | Simon Riggs <simon(at)2ndQuadrant(dot)com> |
---|---|
To: | Ganesh Venkitachalam-1 <ganesh(at)vmware(dot)com> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Latch implementation |
Date: | 2010-09-23 13:56:38 |
Message-ID: | 1285250198.2029.1484.camel@ebony |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On Wed, 2010-09-22 at 13:31 -0700, Ganesh Venkitachalam-1 wrote:
> Hi,
>
> I've been playing around with measuring the latch implementation in 9.1,
> and here are the results of a ping-pong test with 2 processes signalling
> and waiting on the latch. I did three variations (linux 2.6.18, nehalem
> processor).
>
> One is the current one.
>
> The second is built on native semaphors on linux. This one cannot
> implement WaitLatchOrSocket, there's no select involved.
That looks interesting. If we had a need for a latch that would not need
to wait on a socket as well, this would be better. In sync rep, we
certainly do. Thanks for measuring this.
Question is: in that case would we use latches or a PGsemaphore?
If the answer is "latch" then we could just have an additional boolean
option when we request InitLatch() to see what kind of latch we want.
> The third is an implementation based on pipe() and poll. Note: in its
> current incarnation it's essentially a hack to measure performance, it's
> not usable in postgres, this assumes all latches are created before any
> process is forked. We'd need to use mkfifo to sort that out if we really
> want to go this route, or similar.
>
> - Current implementation: 1 pingpong is avg 15 usecs
> - Pipe+poll: 9 usecs
> - Semaphore: 6 usecs
Pipe+poll not worth it then.
--
Simon Riggs www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Training and Services
From | Date | Subject | |
---|---|---|---|
Next Message | Csaba Nagy | 2010-09-23 13:59:30 | Re: Configuring synchronous replication |
Previous Message | Heikki Linnakangas | 2010-09-23 13:55:46 | Re: Latch implementation |