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 20030311053033.GH79234@perrin.int.nxad.com
Whole thread Raw
In response to Re: pgsql-server/ /configure /configure.in rc/incl ...  (Tom Lane <tgl@sss.pgh.pa.us>)
List pgsql-committers
> > 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
>
> That change was not sold as a performance improvement; I doubt that
> it is one.  It was sold as not failing when libpq runs inside an
> application that has thousands of open files (i.e., more than
> select() can cope with).  "Faster" is debatable, "fails" is not...

Well, I've only heard through 2nd hand sources (dillion) the kind of
hellish conditions that Mark has on his boxen, but "faster and more
efficient in the kernel" is "faster and more efficient in the kernel"
no matter how 'ya slice it and I know that every last bit helps a
loaded system.

I'm not stating that most people, or even 90% of people, will notice.
Hopefully 100% of the universe runs their boxen under ideal conditions
(like most databases should, right?  ::wink wink, nudge nudge:: For
those that don't, however, and get to watch things run in the red with
a load average over 20, the use of kqueue or more efficient system
calls is likely very appreciated.  -sc

--
Sean Chittenden

pgsql-committers by date:

Previous
From: Sean Chittenden
Date:
Subject: Re: pgsql-server/ /configure /configure.in rc/incl ...
Next
From: Tom Lane
Date:
Subject: Re: pgsql-server/ /configure /configure.in rc/incl ...