midom.lists at gmail
Mar 11, 2009, 2:20 AM
Post #17 of 31
(7238 views)
Permalink
|
Hello,
just for clarity, "table is full" was the edge case which consisted of
very narrow index, slightly too low MAX_ROWS specification and lots of
rows.
In 4.1 and earlier versions MySQL was using 4-byte data pointers by
default, and to bypass that one has to specify maximum rows and
average row size.
The specifications we had were good for data area, but bad for index
area, which was a function of max_rows and index width.
As index was very very narrow, a 2-byte internal index area pointer
was picked, which allowed just 64k 1024-byte blocks (thats right,
total 64M for indexing per table), which restricted us to ~8 million
rows per table. Of course, that was way above the one million we
specified :)
This is quite unpopular situation (I've never seen anyone hit that
before, except on our sites :) - and if we had any other additional
index on that table or had wider field or more fields in it, the index
pointer would be 4 or 6 bytes, thus allowing bazillion rows.
Now, the bad part was that we saw this before, and we knew what causes
this, and still didn't change definition (or simply remove it, we run
5.0 for ES, and it doesn't need this specification, this is legacy
thing).
Still, no need to believe that we ran out of diskspace.
BR,
--
Domas Mituzas -- http://dammit.lt/ -- [[user:midom]]
_______________________________________________
Wikitech-l mailing list
Wikitech-l [at] lists
https://lists.wikimedia.org/mailman/listinfo/wikitech-l
|
1
