From: | Sean Chittenden <sean(at)chittenden(dot)org> |
---|---|
To: | Adrian 'Dagurashibanipal' von Bidder <avbidder(at)fortytwo(dot)ch> |
Cc: | pgsql-hackers(at)postgresql(dot)org |
Subject: | Re: Options for growth |
Date: | 2003-01-23 07:55:23 |
Message-ID: | 20030123075523.GI12075@perrin.int.nxad.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
> > That would depend on the OS. Not many 'pc-based unix' support over
> > 4 GB of memory, some don't even go that far.
>
> > By the way, I too wonder which supported OS platform would support
> > over 4GB of memory on a PC..
>
> Linux? I don't think there's any problem handling more than 4G
> memory in the system. On 32bit architectures, there's of course the
> 3G (I think) per process limit, but as postgres uses multiprocess
> and not multithreading, this issue doesn't hit so soon. Of course,
> if the per process memory is the problem, you'd have to go to 64bit.
Heh, don't kid yourself. x86 can only handle 4GB of memory
addressing. The hack that Linux uses is to swap out 2GB sections of
RAM to a 4GB+ memory range, then copy the memory range it needs down
into usable memory space. Can we say large page tables? :)
You need an actual 64bit CPU to access more than 4GB of RAM without
paying for it through the nose. -sc
--
Sean Chittenden
From | Date | Subject | |
---|---|---|---|
Next Message | am | 2003-01-23 08:04:42 | Re: Windows Build System |
Previous Message | Justin Clift | 2003-01-23 05:40:30 | Re: [HACKERS] C++ coding assistance request for a visualisation tool |