Döhr, Markus ICC-H wrote:
Hi!
> [...]
>
>>And even if I had enough RAM to keep only 6 GB: At the
>>current read-spead of the DB it takes almost 2 hours to
>>completely slurp in the data.
>>
>>Working with this system you can actually feel this: If you
>>access something by an index that is currently not cached it
>>takes _ages_ - subsequent accesses are as quick as you would expect.
>>
>>I'd like to hear something from SAP here: What kind of
>>hardware do they suggest for proper i/o-performance?
> We are seeing this too - and IMHO it's not the I/O subsystem that is causing
> issues but the sequential read of the database itself (no PQO, no prefetch
> (yet)).
i dont really care - it's inside the DB :)
> We're actually seeing this when we're exporting a (SAP) database of ~ 150
> GB. It takes about 28 hours to determin the size of the tables (via select
> count(*) <tablename>) - over the weekend on a not loaded EVA system. The
> parallel export itself is then done in 4 hours.
isnt the engine supposed to know the size of tables? that's what they
told us at TU-Berlin when they showed some internals some years ago - i
still have the slides :)
but i know that this optimization does not exist.
> This issue is known and AFAIK beeing worked on.
it's known for ages and it should've been solved with 7.6 - i'm really
curious if anything will happen at all :(
Raimund
--
*NEWS* Pinuts präsentiert neue Entwicklungen auf der CeBIT 2006
Vereinbaren Sie einen Termin, http://www.pinuts.de/cebit06
Pinuts media+science GmbH http://www.pinuts.de
Dipl.-Inform. Raimund Jacob [EMAIL PROTECTED]
Krausenstr. 9-10 voice : +49 30 59 00 90 322
10117 Berlin fax : +49 30 59 00 90 390
Germany
--
MaxDB Discussion Mailing List
For list archives: http://lists.mysql.com/maxdb
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
