I repaired a 1 million row table (wasn't anything wrong with it) and it
took 2.5 hours. This is really slow and the problem may be it didn't use
much memory during the process. It probably needed more memory to build
the index. Is there a way to allocate more memory to this process to
speed things up? Maybe in a screen prior to repairing the table you
could allow the user to enter a number like 100MB to aid in the
repair/index building?

Dave

Dave


2.5 hours is good - try a 150k record table in DBISAM with a few FTI fields if you like slooooow.


Roy Lambert

Roy Lambert wrote:

> Dave
>
>
> 2.5 hours is good - try a 150k record table in DBISAM with a few FTI fields if you like slooooow.
>
>
> Roy Lambert
>

Roy,
   I think it is because there is not enough memory used for building
the indexes. I know with MySQL if I'm building an index on a 50 million
row table and I don't pre-allocate enough memory for the indexes, it
will literally take 100x longer because the temporary index is being
built on the hard drive instead of in memory. I noticed during the
ElevateDb repair process hardly any memory was being used. So if I could
throw 200MB at it (or 1gb) then it should take a fraction of the time,
or so I'm hoping.

Dave

Dave,

<< I repaired a 1 million row table (wasn't anything wrong with it) and it
took 2.5 hours. This is really slow and the problem may be it didn't use
much memory during the process. It probably needed more memory to build the
index. Is there a way to allocate more memory to this process to speed
things up? Maybe in a screen prior to repairing the table you could allow
the user to enter a number like 100MB to aid in the repair/index building?
>>

The only way to increase the memory is to increase the memory buffering
settings for the table definition:

http://www.elevatesoft.com/edb1sql_alter_table.htm

You have to remember that EDB is not designed to be used *solely* as a
database server.   Because of this, it will not behave like MySQL or other
engines that only operate as a database server exclusively when it comes to
memory buffering and allocation.

We are planning on an enterprise version of EDB later on that will be a
server-only implementation that will be more like what you are expecting in
this area and in the areas of locking/transaction models.

--
Tim Young
Elevate Software
www.elevatesoft.com