> For example SELECT from Table EBAN with index use, runs > sometimes about 20 seconds. > > If the database is in the cache, the result set is within 500 > milliseconds on my client.
What do you mean with "if the database is in the cache"? The problem is not only which strategy is used but also how many rows are returned. Our EBAN for example has 159413 distinct values so if you do "select *" then all these entries have to be read, no matter if read as index only or table scan, they have to be read from the harddisk/the cache. The cache itself works with a displacement algorithm (IMHO) so the data that is most often read, is kept in the cache, other data not. DATA_CACHE (or CACHE_SIZE) can't be big enough, it's never too big. And since you have only one connection that reads data (so only one thread is used) it doesn't matter how many devspaces you have in that case. I CAN be important concerning I/O, a general recommendation is that DEVSPACES are as big as the harddisks are, so that you get a) no overlapping/competing I/O b) enough I/O to spread over the disks. SIEGENIA-AUBI KG Informationswesen i.A. Markus D�hr SAP-CC/BC, SAPDB-DBA Tel.: +49 6503 917-152 Fax: +49 6503 917-7152 E-Mail: [EMAIL PROTECTED] Internet: http://www.siegenia-aubi.com -- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
