thanks for answering. Yes, we did this.
Recreation of indices, update statistics nothing bars MaxDB from doing table scans (ignoring indices for joining tables).
So, to put it in a nutshell:
- both databases has "new" update statistics, and of course same indices.
- the described problem is hardware independant (we switched between different servers)
- we ran same statement on 7.3.0.46 and 7.5.0.5 on SuSE Linux 9.0
- 7.3.0.46 uses indices whenever possible
- 7.5.0.5 skips using a unique index on 2 columns and therefore performs a table scan (result from our first test, more tests will come soon)
=> result: cost value from MaxDB is 10 times the value of 7.3.xx and also the server load is extremely high for handling one or two connections.
! This currently prevents us from upgrading to MaxDB on our "real" database with very high load (~ 3 requests / sec.) !
any help appreciated ....GERD....
[EMAIL PROTECTED] wrote:
Hello Gerd,
First thing to consider: Have you run UPDATE STATISTICS on both systems before doing your tests?
In my experience... if MaxDB has out of date statistics, it will sometimes think the table is small and a table scan will seem easier :)
Stephen Gutknecht
On Tue, 6 Apr 2004 17:39 , Gerd K�nig <[EMAIL PROTECTED]> sent:
Hi,
we're wondering about the heavy load our maxdb produces.
After some time of investigation we found out that the database produces
a lot of table scans.
Why we are wondering is, that our currently running 7.3.0.46 doesn't produce
table scans, furthermore this version uses the created indices (and MaxDB doesn't...).
An "explain" of a test statement shows us a completely different behaviour of statement execution. The costvalue from MaxDB is 10-times the value from the 7.3.0.46 :-((
This behaviour is hardware-independant (we tested different cases), and we wanted to know if there is a possibility to force MaxDB using indices for reducing load.
The explain outputs of our test-statement for both cases are attached.
Perhaps problems with multiple-column indices ???
We want to upgrade our currently running database version, so we need help, because this heavy load isn't that funny...
thanks a lot -GERD-
-- MaxDB Discussion Mailing List For list archives: http://lists.mysql.com/maxdb To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
