On Tue, May 22, 2018 at 12:07 PM Thomas Munro
<thomas.munro@enterprisedb.com> wrote:
> On Mon, May 21, 2018 at 7:27 PM, Mateusz Guzik <mjguzik@gmail.com> wrote:
> > I have benchmarked the change on a FreeBSD box and found an big
> > performance win once the number of clients goes beyond the number of
> > hardware threads on the target machine. For smaller number of clients
> > the win was very modest.
>
> So to summarise your results:
>
> 32 connections: ~445k -> ~450k = +1.2%
> 64 connections: ~416k -> ~544k = +30.7%
> 96 connections: ~331k -> ~508k = +53.6%
I would like to commit this patch for PostgreSQL 12, based on this
report. We know it helps performance on macOS developer machines and
big FreeBSD servers, and it is the right kernel interface for the job
on principle. Matteo Beccati reported a 5-10% performance drop on a
low-end Celeron NetBSD box which we have no explanation for, and we
have no reports from server-class machines on that OS -- so perhaps we
(or the NetBSD port?) should consider building with WAIT_USE_POLL on
NetBSD until someone can figure out what needs to be fixed there
(possibly on the NetBSD side)?
Here's a rebased patch, which I'm adding to the to November CF to give
people time to retest, object, etc if they want to.
--
Thomas Munro
http://www.enterprisedb.com