Skip site navigation (1) Skip section navigation (2)

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

From: Sean Chittenden <sean(at)chittenden(dot)org>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Christopher Kings-Lynne <chriskl(at)familyhealth(dot)com(dot)au>,pgsql-committers(at)postgresql(dot)org
Subject: Re: pgsql-server/ /configure /configure.in rc/incl ...
Date: 2003-03-06 09:41:17
Message-ID: 20030306094117.GA79234@perrin.int.nxad.com (view raw or flat)
Thread:
Lists: pgsql-committerspgsql-performance
> >>> 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.

That said, in terms of performance perks, I'd think migrating the
backend to using mmap() would yield a bigger performance benefit (see
Stevens) to a larger group of people than adding FreeBSD's kqueue
interface (something I plan on doing at some point if no one beats me
to it).  mmap() + write() for FreeBSD is a zero-copy socket operation
and likely is on other platforms.  Reducing the number of pages that
have to be copied around would be a big win in terms of sending data
to clients as well as scanning through data.  Files are also only
mmap()'ed in the kernel once with BSD's VM system which could reduce
the RAM consumed by backends considerably.

mmap() would also be an interesting way of providing some kind of
atomicity for MVCC (re: WAL, use msync() to have the mapped region hit
the disk before the change). I was actually quite surprised when I
grep'ed through the code and found that mmap() wasn't in use
_anywhere_.  The TODO seems to be full of messages, but not much in
the way of authoritative statements.  Is this one of the areas of
PostgreSQL that just needs to get slowly migrated to use mmap() or are
there any gaping reasons why to not use the family of system calls?

-sc

-- 
Sean Chittenden

In response to

Responses

pgsql-performance by date

Next:From: Mr.FDate: 2003-03-06 10:51:28
Subject: New Interface for Win
Previous:From: Shridhar DaithankarDate: 2003-03-06 06:53:42
Subject: Re: Batch copying of databases

pgsql-committers by date

Next:From: Tom LaneDate: 2003-03-06 15:25:36
Subject: Re: pgsql-server/ /configure /configure.in rc/incl ...
Previous:From: Bruce MomjianDate: 2003-03-06 04:33:36
Subject: Re: pgsql-server/ /configure /configure.in rc/incl ...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group