Re: pgsql-server/ /configure /configure.in rc/incl ...
От | Tom Lane |
---|---|
Тема | Re: pgsql-server/ /configure /configure.in rc/incl ... |
Дата | |
Msg-id | 15071.1046964336@sss.pgh.pa.us обсуждение исходный текст |
Ответ на | pgsql-server/ /configure /configure.in rc/incl ... (tgl@postgresql.org (Tom Lane)) |
Ответы |
Re: pgsql-server/ /configure /configure.in rc/incl ...
|
Список | 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 по дате отправления: