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