Bug #9170 Dynamic Pointer Resizing
Submitted: 14 Mar 2005 16:49
Reporter: Cornelius Sybrandy Email Updates:
Status: Open Impact on me:
None 
Category:MySQL Server: MyISAM storage engine Severity:S4 (Feature request)
Version: OS:
Assigned to: CPU Architecture:Any
Triage: D5 (Feature request)

[14 Mar 2005 16:49] Cornelius Sybrandy
Description:
A feature that may prove useful and could potentially make maintenance easier is to have the MyISAM storage engine, and perhaps others, use dynamically resizing pointers.

Background: currently, MyISAM default to using 32-bit pointers, which restricts the size of the table to 4Gb.  We can work around this using the MAX_ROWS and AVG_ROW_SIZE parameters or by changing a configuration variable. (Don't remember which one right now.)  This means that if someone is unaware of this limiation, they could hit the 4Gb limit and not know how to overcome it.  Granted, there are ways to do it, but that's not the point.  Let's assume they still want a single table.

What I'm proposing is that the storage engine be intelligent enough to detech when the 32-bit size limit has been exceeded and increase it accordingly.  This way, for smaller tables, you still have the speed benefit of a 32-bit pointer, but you can grow with less effort.

Another benefit of this could be that if one is on a 64-bit architecture, the default pointer size is changed to 64-bit since, based on my limited knowledge, a 64-bit operation would be faster than a 32-bit operation on such a platform.

How to repeat:
No instructions.
[15 Mar 2007 10:18] Ingo Strüwing
Please note that changing the data pointer size implies at least a full rebuild of  the whole index file with all indexes.

This means that after a huge amount of inserts, one of them suddenly takes virtually forever. With todays disk performance this might be somewhat acceptable when changing data pointer size from 4 to 5. But when the same happens from 5 to 6, users will probably kill the server and complain. If it is an important table, the server can become unusable for hours.

Isn't it better to schedule such events in advance?

And we have 6 byte pointers by default since 5.0.6.