In such a case you save a lot of space on tables + indexes, semplify accesses to simpler indexes. Two or three years ago, all that space saving could mean a lot (and a lot of IOs less).
Tonino
At 19/10/02 19/10/02 -0600, Tren Blackburn wrote:
*shrug* It's not my answer. That is the answer I got from one of the developers about 2 years ago. Maybe things have changed. Also, it makes more sense to reply to the list. I'm not one of the developers. I've been using this package for a very long time however (almost 4 years now) and I'm quite familiar with this package, however you're cutting off discussion when you reply only to me. Also, if you're confident in what you've found out, try to implement it, see how it works, check performance against both types of table layout. It's opensource, no one is stopping you just because the documentation recommends doing something a certain way.Regards, Tren -----Original Message----- From: Matthias Trevarthan [mailto:trevarthan@;wingnet.net] Sent: Friday, October 18, 2002 12:27 PM To: Tren Blackburn Subject: Re: [vchkpw] multi-table mysql domains Well, that's not true though. You can configure MySQL to have more than 64 tables open at one time. You can configure it to 800 tables open at one time if you want. Take a look at the MySQL documentation, section 5.4.7: ------------------------------------------------------------------------ -- "table_cache, max_connections, and max_tmp_tables affect the maximum number of files the server keeps open. If you increase one or both of these values, you may run up against a limit imposed by your operating system on the per-process number of open file descriptors. However, you can increase the limit on many systems. Consult your OS documentation to find out how to do this, because the method for changing the limit varies widely from system to system. table_cache is related to max_connections. For example, for 200 concurrent running connections, you should have a table cache of at least 200 * n, where n is the maximum number of tables in a join. You also need to reserve some extra file descriptors for temporary tables and files. Make sure that your operating system can handle the number of open file descriptors implied by the table_cache setting. If table_cache is set too high, MySQL may run out of file descriptors and refuse connections, fail to perform queries, and be very unreliable. You also have to take into account that the MyISAM table handler needs two file descriptors for each unique open table. You can in increase the number of file descriptors available for MySQL with the --open-files-limit=# startup option. See section A.2.16 File Not Found. The cache of open tables will be keept at a level of table_cache entries (default 64; this can be changed with the -O table_cache=# option to mysqld). Note that in MySQL may temporarly open even more tables to be able to execute queries. " ------------------------------------------------------------------------ - So, is that the only anwser? You'll have to do better than that to convince me. On Friday 18 October 2002 13:44, Tren Blackburn wrote: > As I recall, mysql can only have 64 tables open at a time. It might > have a different limit on different OS's but for Linux that's the > issue. > > Regards, > > Tren > > -----Original Message----- > From: Matthias Trevarthan [mailto:trevarthan@;wingnet.net] > Sent: Friday, October 18, 2002 11:16 AM > To: [EMAIL PROTECTED] > Subject: [vchkpw] multi-table mysql domains > > > Howdy, > > I'm just curious, but why does the documentation frown upon multiple > tables for multiple domains? > > Is it the per process file descriptor thing? (After all, that's not so > much of a UNIX thing as a Linux thing. FreeBSD doesn't have per > process limits. It > has system limits, but they're tunable.) > > Or is it something else? I would think that throwing multiple domains > and users into one table is poor database design. Not only is it more > difficult > to back up and administer, but I would think it would be slower! After > all, > if you have 10,000 users in one domain, and only 500 in another, it'd be > > inefficient to search for those 500 users among 10,000. > > Matthias
------------------------------------------------------------
Inter@zioni Interazioni di Antonio Nati
http://www.interazioni.it [EMAIL PROTECTED]
------------------------------------------------------------
