List:General Discussion« Previous MessageNext Message »
From:Michael Widenius Date:January 28 2000 2:50am
Subject:Re: Irrelevant ...mmap() VS read()
View as plain text  
>>>>> "Mathijs" == Mathijs Brands <mathijs@stripped> writes:

Mathijs> On Wed, Jan 26, 2000 at 10:42:20AM +0200, Michael Widenius allegedly wrote:
>> Hi!
>> We already do the above for compressed tables; We plan to do the above
>> also for other tables in the future;  The main problem with using mmap
>> are:
>> - What happens if you get a read error (and how to detect which file+thread
>> got the read error)
>> - How to extend the file+mmap area if needed;  This is particularly
>> tricky when using threads that may be reading the file as you try to
>> insert new rows.
>> - How to deal with memory fragmentation issues on 32 bit
>> operating systems;  Just having many files that grows can easily
>> take up your whole process memory and not leave enough room for the
>> normal memory that MySQL needs.
>> Regards,
>> Monty

Mathijs> What about tables bigger than 2 GB? Does MySQL use the increased
> addressingspace
Mathijs> on a 64 bit architecture?

Yes;  MySQL can handle big files if the underlaying OS supports it.

The new RAID option can expand the barrier on 32 bit systems, but this
is still in testing!

Irrelevant ...mmap() VS read()Mark Papadakis9 Jan
  • Re: Irrelevant ...mmap() VS read()Sasha Pachev10 Jan
    • Re: Irrelevant ...mmap() VS read()elble10 Jan
      • Re: Irrelevant ...mmap() VS read()Michael Widenius26 Jan
        • Re: Irrelevant ...mmap() VS read()Mathijs Brands27 Jan
          • Re: Irrelevant ...mmap() VS read()Michael Widenius28 Jan
            • Re: Irrelevant ...mmap() VS read()Mathijs Brands29 Jan
              • Re: Irrelevant ...mmap() VS read()Michael Widenius29 Jan
    • Re: Irrelevant ...mmap() VS read()Mike Wexler10 Jan
  • Irrelevant ...mmap() VS read()Michael Widenius11 Jan