Dave


Maybe this weekend I found the results interesting, especially how consistent ElevateDB and DBISAM were regardless of index before or after. For pure speed it looks like I'll have to go back to Paradox though - I can feel the support calls already.

Roy Lambert

Roy Lambert wrote:

> Dave
>
>
> Maybe this weekend I found the results interesting, especially how consistent ElevateDB and DBISAM were regardless
> of index before or after. For pure speed it looks like I'll have to go back to Paradox though -
> I can feel the support calls already.
>
> Roy Lambert
>
Roy,
   Agreed. How about starting our own Paradox support group so we can
get rich taking support calls? Give me your phone number and I'll have
it on www.Paradox4Wimps.com by this afternoon.

The weird thing about Paradox is it runs at roughly the same speed
whether the index is built ahead of time or not. So unlike the other
databases, there is no performance penalty when adding data to a table
with an index. (I'm recommending Paradox, I'm just pointing out an anomaly).

   Unfortunately none of the other databases can quickly add 20 million
rows to a table. It will take about a day which is much too long.

Dave

"(I'm recommending Paradox, I'm just pointing out an anomaly). "

Sorry that was a typo. I meant to say
"(I'm *not* recommending Paradox, I'm just pointing out an anomaly)."

Dave

Dave,

<< The weird thing about Paradox is it runs at roughly the same speed
whether the index is built ahead of time or not. So unlike the other
databases, there is no performance penalty when adding data to a table with
an index. (I'm recommending Paradox, I'm just pointing out an anomaly). >>

Did you turn on Local Share for the BDE ?  If you didn't, then Paradox is
effectively caching the entire table, which is why it doesn't suffer any
performance issues.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:

> Dave,
>
> << The weird thing about Paradox is it runs at roughly the same speed
> whether the index is built ahead of time or not. So unlike the other
> databases, there is no performance penalty when adding data to a table with
> an index. (I'm recommending Paradox, I'm just pointing out an anomaly). >>
>
> Did you turn on Local Share for the BDE ?  If you didn't, then Paradox is
> effectively caching the entire table, which is why it doesn't suffer any
> performance issues.
>

The application is dedicated to importing the data and is not expected
to be shared during this process. I tried locking the other database
tables and it did not seem to improve the speed much. If there is a way
to improve DBISAM or EDB's speed in the same way, I'm all for it.

Dave

Dave,

<< The application is dedicated to importing the data and is not expected to
be shared during this process. I tried locking the other database tables and
it did not seem to improve the speed much. If there is a way to improve
DBISAM or EDB's speed in the same way, I'm all for it. >>

You're missing my point.  My point is that testing a database engine that
doesn't actually write anything to disk at any point during the process is
basically a non-test since it does nothing to show how good the buffer
manager is in terms of cache hit/miss ratios, etc.  All you're showing is
that the database engine can consume a large amount of memory.

I suppose it would be possible to add an EXCLUSIVE clause to the IMPORT
TABLE statement to allow for an exclusive import of the table.  However,
that would preclude any other session from even opening the table during the
process.

See my other response regarding your benchmark test.

--
Tim Young
Elevate Software
www.elevatesoft.com