Re: pgsql-server/ /configure /configure.in rc/incl ...

Поиск
Список
Период
Сортировка
От Sean Chittenden
Тема Re: pgsql-server/ /configure /configure.in rc/incl ...
Дата
Msg-id 20030311045610.GF79234@perrin.int.nxad.com
обсуждение исходный текст
Ответ на Re: pgsql-server/ /configure /configure.in rc/incl ...  (Neil Conway <neilc@samurai.com>)
Ответы Re: pgsql-server/ /configure /configure.in rc/incl ...  (Tom Lane <tgl@sss.pgh.pa.us>)
Список 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 по дате отправления:

Предыдущее
От: "Christopher Kings-Lynne"
Дата:
Сообщение: Re: pgsql-server/ /configure /configure.in rc/incl ...
Следующее
От: Sean Chittenden
Дата:
Сообщение: Re: pgsql-server/ /configure /configure.in rc/incl ...