From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | PostgreSQL-development <pgsql-hackers(at)postgreSQL(dot)org> |
Subject: | [PATCHES] A patch for xlog.c |
Date: | 2001-02-26 02:00:41 |
Message-ID: | 200102260200.VAA17397@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
[ Send to hackers]
> I'd be willing to consider using mmap as a compile-time option if it
> can be shown to be a substantial performance win where it's available.
> (I suspect that's a very big "if".) If it's not a substantial win,
> I don't think we should accept the change --- the portability risks and
> testing/maintenance costs loom too large for me.
>
I was considering it because you can use a much larger amount of shared
memory without reconfiguring the kernel.
> BTW, how exactly is mmap a substitute for SysV shared memory? AFAICT
> it's only defined to map a disk file into your address space, not to
> allow a shared memory region to be set up that's independent of any
> disk file.
It allows no backing store on disk. It is the BSD solution to SysV
share memory. Here are all the BSDi flags:
MAP_ANON Map anonymous memory not associated with any specific file.
The file descriptor used for creating MAP_ANON must be -1.
The offset parameter is ignored.
MAP_FIXED Do not permit the system to select a different address than
the one specified. If the specified address cannot be used,
mmap will fail. If MAP_FIXED is specified, addr must be a
multiple of the pagesize. Use of this option is discouraged.
MAP_PRIVATE
Modifications are private.
MAP_SHARED Modifications are shared.
We would use MAP_ANON|MAP_SHARED I guess.
--
Bruce Momjian | http://candle.pha.pa.us
pgman(at)candle(dot)pha(dot)pa(dot)us | (610) 853-3000
+ If your life is a hard drive, | 830 Blythe Avenue
+ Christ can be your backup. | Drexel Hill, Pennsylvania 19026
From | Date | Subject | |
---|---|---|---|
Next Message | Lincoln Yeoh | 2001-02-26 02:01:17 | Re: RE: Re: [ADMIN] v7.1b4 bad performance |
Previous Message | Lincoln Yeoh | 2001-02-26 01:26:47 | Re: Re: offset and limit in update and subselect |