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 ...
|
Список | 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 по дате отправления: