On Fri, Jun 17, 2016 at 2:23 PM, Aleksey Demakov <adema...@gmail.com> wrote: > Essentially this is pessimizing for the lowest common denominator > among OSes.
I totally agree. That's how we make the server portable. > Having a contiguous address space makes things so > much simpler that considering this case, IMHO, is well worth of it. I think that would be great if you could make it work, but it has to support Linux, Windows (all supported versions), MacOS X, all the various BSD flavors for which we have buildfarm animals, and other platforms that we currently run on like HP-UX. If you come up with a solution that works for this on all of those platforms, I will shake your hand. But I think that's probably impossible, or at least really, really hard. > You are right that this might highly depend on the OS. But you are > only partially right that it's impossible to give the memory back once > you touched it. It is possible in many cases with additional measures. > That is with additional control over memory mapping. Surprisingly, in > this case windows has the most straightforward solution. VirtualAlloc > has separate MEM_RESERVE and MEM_COMMIT flags. On various > Unix flavours it is possible to play with mmap MAP_NORESERVE > flag and madvise syscall. Finally, it's possible to repeatedly mmap > and munmap on portions of a contiguous address space providing > a given addr argument for both of them. The last option might, of > course, is susceptible to hijacking this portion of the address by an > inadvertent caller of mmap with NULL addr argument. But probably > this could be avoided by imposing a disciplined use of mmap in > postgresql core and extensions. I have never understood how mmap() with a non-NULL argument could be anything but a giant foot-gun. If the operation system positions a shared library or your process stack or anything else in the chosen address range, you are dead. I do agree that there are a bunch of other tools that could be used on various platforms, but the need to have a cross-platform solution for anything that goes into core makes this very hard. > Thus providing a single contiguous shared address space is doable. Not convinced. > The other question is how much it would buy. As for development > time of an allocator it is a clear win. In terms of easy passing direct > memory pointers between backends this a clear win again. I agree it would be a huge win if it could be done. > In terms of resulting performance, I don't know. This would take > a few cycles on every step. You have a shared hash table. You > cannot keep pointers there. You need to store offsets against the > base address. Any reference would involve additional arithmetics. > When these things add up, the net effect might become noticeable. I'm sure it's going to be somewhat slower, but I think that's just a tax that we have to pay for using processes rather than threads. I think it's still going to be fast enough to do plenty of cool stuff. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
