From: | Samuel Williams <space(dot)ship(dot)traveller(at)gmail(dot)com> |
---|---|
To: | pgsql-general <pgsql-general(at)postgresql(dot)org> |
Subject: | libpq read/write |
Date: | 2019-03-30 11:20:20 |
Message-ID: | CAHkN8V_zTfF9QAwG_rrM=k6U56xvnEyNsUDi9_=vOg7UZHgF_A@mail.gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
I've been doing some profiling and I was surprised to see that libpq uses
epoll when handling what essentially amounts to blocking reads/writes.
I was just wondering why it needed to be so complicated?
What's wrong with just using read/write when blocking semantics are
desired? You can still restart them if they are interrupted (might not be
desired default behaviour). The problem is, it's hard for me to measure
"blocking" time when libpq uses epoll rather than blocking read/write.
I guess I'm not expecting to rewrite it or anything, just wondering why
it's designed that way.
Kind regards,
Samuel
From | Date | Subject | |
---|---|---|---|
Next Message | Gmail | 2019-03-30 11:51:02 | Re: stale WAL files? |
Previous Message | Ankit Trivedi | 2019-03-30 11:09:51 | Required postgreSQL 10.4 version for Suse enterprise |