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

From Tom Lane
Subject Re: pgsql-server/ /configure /configure.in rc/incl ...
Date
Msg-id 15071.1046964336@sss.pgh.pa.us
Whole thread Raw
In response to pgsql-server/ /configure /configure.in rc/incl ...  (tgl@postgresql.org (Tom Lane))
Responses Re: pgsql-server/ /configure /configure.in rc/incl ...
List pgsql-committers
Sean Chittenden <sean@chittenden.org> writes:
> 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.

From what I've looked at, kqueue only wins when you are watching a large
number of file descriptors at the same time; which is an operation done
nowhere in Postgres.  I think the above would be a complete waste of
effort.

> 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?

There has been much speculation on this, and no proof that it actually
buys us anything to justify the portability hit.  There would be some
nontrivial problems to solve, such as the mechanics of accessing a
large number of files from a large number of backends without running
out of virtual memory.  Also, is it guaranteed that multiple backends
mmap'ing the same block will access the very same physical buffer, and
not multiple copies?  Multiple copies would be fatal.  See the acrhives
for more discussion.

            regards, tom lane

pgsql-committers by date:

Previous
From: Bruce Momjian
Date:
Subject: Re: pgsql-server/ /configure /configure.in rc/incl ...
Next
From: momjian@postgresql.org (Bruce Momjian - CVS)
Date:
Subject: pgsql-server/doc TODO