WaitLatchOrSocket optimization

Hi hackers,

Right now function WaitLatchOrSocket is implemented in very inefficient
way: for each invocation it creates epoll instance, registers events and
then closes this instance.
Certainly it is possible to create wait event set once with
CreateWaitEventSet and then use WaitEventSetWait.
And it is done in most performance critical places.
But there are still lot of places in Postgres where WaitLatchOrSocket or
WaitLatch are used.

One of them is postgres_fdw.
If we run pgbench through postgres_fdw (just redirect pgbench tables
using postgres_fdw to the localhost),
then at the system with large number (72) of CPU cores, "pgbench -S -M
prepared -c 100 -j 32" shows performance about 38k TPS with the
following profile:

-   73.83%     0.12%  postgres         postgres [.] PostgresMain ▒
   - 73.82% PostgresMain ▒
      + 28.18% PortalRun ▒
      + 26.48% finish_xact_command ▒
      + 13.66% PortalStart ▒
      + 1.83% exec_simple_query ▒
      + 1.22% pq_getbyte ▒
      + 0.89% ReadyForQuery ▒
-   66.04%     0.03%  postgres         [kernel.kallsyms] [k]
entry_SYSCALL_64_fastpath ▒
   - 66.01% entry_SYSCALL_64_fastpath ▒
      + 61.39% syscall_return_slowpath ▒
      + 1.52% sys_epoll_create1 ▒
      + 1.30% SYSC_sendto ▒
      + 0.94% sys_epoll_pwait ▒
        0.57% SYSC_recvfrom ▒
-   65.61%     0.03%  postgres         postgres_fdw.so [.]
pgfdw_get_result ▒
   - 65.58% pgfdw_get_result ▒
      - 65.00% WaitLatchOrSocket ▒
         + 62.60% __close ▒
         + 1.62% CreateWaitEventSet ▒
-   65.09%     0.02%  postgres         postgres [.] WaitLatchOrSocket ▒
   - 65.08% WaitLatchOrSocket ▒
      + 62.68% __close ▒
      + 1.62% CreateWaitEventSet ▒
+   62.69%     0.02%  postgres         libpthread-2.26.so [.] __close ▒

So, you can see that more than 60% of CPU is spent in close.

If we cache used wait event sets, then performance is increased to 225k
TPS: five times!
At the systems with smaller number of cores effect of this patch is not
so large: at my desktop with 4 cores I get just about 10% improvement at
the same test.

There are two possible ways of fixing this issue:
1. Patch postgres_fdw to store WaitEventSet in connection.
2. Patch WaitLatchOrSocket to cache created wait event sets.

Second approach is more generic and cover all cases of WaitLatch usages.
Attached patch implements with approach.
The most challenging  of this approach is using  socket descriptor as
part of hash code.
Socket can be closed be already and reused, so cached epoll set will not
work any more.
To solve this issue I always try to add socket to the epoll set,
ignoring EEXIST error.
Certainly it will add some extra overhead, but looks like it is
negligible comparing with overhead of close (if I comment this branch,
then pgbench performance is almost the same - 227k TPS).
But if there are some other arguments against using cache in
WaitLatchOrSocket, we have a patch particularly for postgres_fdw.

--
Konstantin Knizhnik
Postgres Professional: http://www.postgrespro.com
The Russian Postgres Company