On Wed, Sep 22, 2010 at 4:31 PM, Ganesh Venkitachalam-1
<ganesh@vmware.com> wrote:
> 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.
>
> 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
Interesting numbers. I guess one question is how much improving the
performance of the latch implementation would affect overall system
performance. Synchronous replication is obviously going to be highly
sensitive to latency, but even in that context I'm not really sure
whether this is enough to matter. Do you have any sense of that?
--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise Postgres Company