| From: | Andres Freund <andres(at)anarazel(dot)de> |
|---|---|
| To: | Konstantin Knizhnik <k(dot)knizhnik(at)postgrespro(dot)ru> |
| Cc: | PostgreSQL Hackers <pgsql-hackers(at)postgresql(dot)org> |
| Subject: | Re: WaitLatchOrSocket optimization |
| Date: | 2018-03-15 17:25:14 |
| Message-ID: | 20180315172514.tm47h4do4clfmif7@alap3.anarazel.de |
| Views: | Raw Message | Whole Thread | Download mbox | Resend email |
| Thread: | |
| Lists: | pgsql-hackers |
Hi,
On 2018-03-15 19:01:40 +0300, Konstantin Knizhnik wrote:
> Right now function WaitLatchOrSocket is implemented in very inefficient way:
> for each invocation it creates epoll instance, registers events and then
> closes this instance.
Right, everything performance critical should be migrated to using a
persistent wait even set.
> But there are still lot of places in Postgres where WaitLatchOrSocket or
> WaitLatch are used.
Most don't matter performancewise though.
> 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.
I'm strongly opposed to 2). The lifetime of sockets will make this an
absolute mess, it'll potentially explode the number of open file
handles, and some OSs don't handle a large number of sets at the same
time.
Greetings,
Andres Freund
| From | Date | Subject | |
|---|---|---|---|
| Next Message | Catalin Iacob | 2018-03-15 18:14:09 | Re: JIT compiling with LLVM v11 |
| Previous Message | Chapman Flack | 2018-03-15 17:21:37 | Re: worker_spi.naptime in worker_spi example |