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

From Marc G. Fournier
Subject Re: pgsql-server/ /configure /configure.in rc/incl ...
Date
Msg-id 20030310224706.T35660@hub.org
Whole thread Raw
In response to Re: pgsql-server/ /configure /configure.in rc/incl ...  (Sean Chittenden <sean@chittenden.org>)
Responses Re: pgsql-server/ /configure /configure.in rc/incl ...
List pgsql-committers
yOn Thu, 6 Mar 2003, Sean Chittenden wrote:

> > >>> Has anyone ever thought about adding kqueue (for *BSD) support to
> > >>> Postgres, instead of using select?
> > >>
> > >> Why?  poll() is standard.  kqueue isn't, AFAIK.
> >
> > > It's supposed be a whole heap faster - there is no polling involved...
> >
> > Supposed by whom?  Faster than what?  And how would it not poll?
> >
> > The way libpq uses this call, it's either probing for current status
> > (timeout=0) or it's willing to block, possibly indefinitely, until the
> > desired condition arises.  It does not sit there in a busy-wait loop.
> > I can't see any reason to think that an OS-specific API would give
> > any marked difference in performance.
>
> Heh, kqueue is _the_ reason to use FreeBSD.
>
> http://www.kegel.com/dkftpbench/Poller_bench.html#results
>
> I've toyed with the idea of adding this because it is monstrously more
> efficient than select()/poll() in basically every way, shape, and
> form.

I would personally be interested in seeing patches ... what would be
involved?


pgsql-committers by date:

Previous
From: tgl@postgresql.org (Tom Lane)
Date:
Subject: pgsql-server/ ontrib/dbase/dbf2pg.c ontrib/ful ...
Next
From: Sean Chittenden
Date:
Subject: Re: pgsql-server/ /configure /configure.in rc/incl ...