Re: pgsql-server/ /configure /configure.in rc/incl ... - Mailing list pgsql-committers

From Sean Chittenden
Subject Re: pgsql-server/ /configure /configure.in rc/incl ...
Date
Msg-id 20030311045610.GF79234@perrin.int.nxad.com
Whole thread Raw
In response to Re: pgsql-server/ /configure /configure.in rc/incl ...  (Neil Conway <neilc@samurai.com>)
Responses Re: pgsql-server/ /configure /configure.in rc/incl ...
List pgsql-committers
> > It would be nice to have this support there, however Tom was
> > correct in saying it really only applies to network apps that are
> > handling thousands of connections, all really, really fast.
> > Postgres doesn't.  I say you'd have to do the work, then do the
> > benchmarking to see if it makes a difference.
>
> ... and if it doesn't make a significant difference, I'd oppose
> including it in the mainline source. Performance optimization is one
> thing; performance "optimization" that doesn't actually improve
> performance is another :-)

::sigh:: Well, I'm not about to argue one way or another on this
beyond saying: kqueue is better than select/poll, but there are much
bigger, much lower, and much easier pieces of fruit to pick off the
optimization tree given the cost/benefit for the amount of network IO
PostgreSQL does.  That said, what was the performance gain of moving
from select() to poll()?  It wasn't the biggest optimization in
PostgreSQL history, nor the smallest, but it was a step forward.  -sc

--
Sean Chittenden

pgsql-committers by date:

Previous
From: "Christopher Kings-Lynne"
Date:
Subject: Re: pgsql-server/ /configure /configure.in rc/incl ...
Next
From: Sean Chittenden
Date:
Subject: Re: pgsql-server/ /configure /configure.in rc/incl ...