Rick Widmer wrote:
mlist wrote:
John Simpson wrote:
and since mysql has a limit of 64 bytes for a table name, you have
a... maybe not a bug, but a design flaw. the name "aaaaa(63
times).com" IS a valid domain name, but "aaaaa(63 times)_com" is NOT
a valid table name.
Definitely a design flaw, even before the domain name length increase.
I believe Ken once told me it was a mistake, but he never removed it
because people were using it. I think the name length issue is a good
reason to depreciate the feature. I'm looking to reduce the number of
options to ./configure, and this looks like a good candidate.
perhaps you shouldn't store each domain's data in a separate table?
i've never understood the reason for creating separate tables for
each domain anyway- but since i don't normally use a SQL back-end for
mailbox information, it's not something i really worry about.
Well then . . . that explains it. Thanks Rick, Joshua, and John. I'm
no full-time DBA wouldn't it take less time to query through a
specific table looking for data than it would to query one massive
table? Any one else have any thoughts? I'm curious to know which
would perform better.
If I remember right, speed was the reason for separate tables, but
testing showed it was not faster. I think the single table works better
because all your mail users are accessing the same table, and its
indexes so they stay loaded all the time. If you use separate tables it
is always thrashing the cache as different files need to be accessed.
I vote we depreciate the feature if we can provide a script to help
people migrate from the multi table method to the single table
method.
The feature was only intended for sites with one or two domains
and large numbers of users. In that case the database would not
thrash since there would only be a few tables involved. And the
database could save space by not storing the pw_domain field.
As a DBA on large databases I could not resist optimizing this
redundant data.
The space saved on 100,000 users would be 6.4Mbytes
for pw_domain of 64 chars or 12.4Mbytes for pw_domain of 128 chars.
With the amount of RAM and disk space of modern servers the
space saved does not seem significant now.
Considering the confusion this feature generates and the relatively
small amount of space it saves I say it's worth depreciating
the feature.
It should be relatively straight forward to create a migration script
to move a site with many tables to the single table design.
Ken Jones
