Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 6 of 6 total
Thread EDB Mgr suggestions
Sat, Sep 1 2007 12:20 AMPermanent Link

Dave Harrison
I'm using 1.05 and I'm using it to import a DBISAM v4 database and here
are a few thoughts.

1) It would be nice if the user could migrate only certain tables over
to the EDB database. I don't need to import a lot of temporary tables,
or backup tables.

2) Allow the user to specify how much RAM can be dedicated to importing
the data. My migration is still running after a couple of hours. It may
run through the night. I have 2gb of RAM and it would be nice if I could
assign 1gb of RAM so it would be much faster at building the indexes.
This could speed things up considerably.

Dave
Sat, Sep 1 2007 8:46 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Dave,

<< I'm using 1.05 and I'm using it to import a DBISAM v4 database and here
are a few thoughts.

1) It would be nice if the user could migrate only certain tables over to
the EDB database. I don't need to import a lot of temporary tables, or
backup tables. >>

The reason behind doing the whole database at all times is the dependency
issues with RI and other references between database objects.  However, I'll
see what I can do, especially since DBISAM and the local BDE engine normally
don't use RI.

<< 2) Allow the user to specify how much RAM can be dedicated to importing
the data. My migration is still running after a couple of hours. It may run
through the night. I have 2gb of RAM and it would be nice if I could
assign 1gb of RAM so it would be much faster at building the indexes. This
could speed things up considerably. >>

This goes back to our conversation on buffering - EDB really isn't capable
of using that much RAM at this time.  The enterprise server version of EDB
will offer this type of memory management.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tue, Sep 4 2007 4:59 PMPermanent Link

Dave Harrison
Tim Young [Elevate Software] wrote:
> Dave,
>
> << I'm using 1.05 and I'm using it to import a DBISAM v4 database and here
> are a few thoughts.
>
>  1) It would be nice if the user could migrate only certain tables over to
> the EDB database. I don't need to import a lot of temporary tables, or
> backup tables. >>
>
> The reason behind doing the whole database at all times is the dependency
> issues with RI and other references between database objects.  However, I'll
> see what I can do, especially since DBISAM and the local BDE engine normally
> don't use RI.

Ok, thanks. It's just that there are usually quite a few scratch tables
(or older versions of existing tables) that don't need to be moved over
to the new database. Not only does it take up unnecessary space, but
time to move the tables as well.

>
> << 2) Allow the user to specify how much RAM can be dedicated to importing
> the data. My migration is still running after a couple of hours. It may run
> through the night. I have 2gb of RAM and it would be nice if I could
> assign 1gb of RAM so it would be much faster at building the indexes. This
> could speed things up considerably. >>
>
> This goes back to our conversation on buffering - EDB really isn't capable
> of using that much RAM at this time.  The enterprise server version of EDB
> will offer this type of memory management.

My rant last month was to improve caching for queries and ranges. My
rant this month is to make better use of existing memory when building
indexes and moving tables. It took 12 hours to move my DBISAM database
over to EDB. I thought this was a bit long. A lot of the time was spent
building the indexes. I know from my experience with MySQL, if I
dedicate more ram (500MB) to the index buffer, it will build the indexes
100x faster!

I'm not sure why ENT version is needed because 2gb of RAM should be
plenty for 30 million row tables. I would have thought EDB would allow
the user to use all addressable memory for buffers like other databases
do, instead of limiting the amount of RAM it can access. But if you're
going to implement AWE in ENT, then paying more for ENT makes sense.

Have you come up with a price for the ENT version. Will it be released
this year?

Dave
Wed, Sep 5 2007 2:56 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Dave,

<< My rant last month was to improve caching for queries and ranges. My rant
this month is to make better use of existing memory when building indexes
and moving tables. >>

I understand, but the two are one and the same issue in terms of how the
database engine allocates memory for buffering purposes.

<< I'm not sure why ENT version is needed because 2gb of RAM should be
plenty for 30 million row tables. I would have thought EDB would allow the
user to use all addressable memory for buffers like other databases
do, instead of limiting the amount of RAM it can access. >>

Well, I could tell you that EDB will let you use that much memory because,
technically, it can.  However, it doesn't give you the performance benefit
that you would want after a certain point because of the fact that the
buffer management overhead starts to limit its effectiveness, so I'm just
being honest with you.  It's the same reason why an OS and database servers
usually use the clock algorithm for buffering instead of using an LRU
algorithm, which is what DBISAM and EDB use.

<< Have you come up with a price for the ENT version. Will it be released
this year? >>

No, and hopefully, but probably not.  I suspect it will be available by
Jan/Feb of next year.

--
Tim Young
Elevate Software
www.elevatesoft.com

Wed, Sep 5 2007 5:59 PMPermanent Link

Dave Harrison
Tim Young [Elevate Software] wrote:
> Dave,
>
> << My rant last month was to improve caching for queries and ranges. My rant
> this month is to make better use of existing memory when building indexes
> and moving tables. >>
>
> I understand, but the two are one and the same issue in terms of how the
> database engine allocates memory for buffering purposes.
>
> << I'm not sure why ENT version is needed because 2gb of RAM should be
> plenty for 30 million row tables. I would have thought EDB would allow the
> user to use all addressable memory for buffers like other databases
>  do, instead of limiting the amount of RAM it can access. >>
>
> Well, I could tell you that EDB will let you use that much memory because,
> technically, it can.  However, it doesn't give you the performance benefit
> that you would want after a certain point because of the fact that the
> buffer management overhead starts to limit its effectiveness, so I'm just
> being honest with you.  It's the same reason why an OS and database servers
> usually use the clock algorithm for buffering instead of using an LRU
> algorithm, which is what DBISAM and EDB use.
>
> << Have you come up with a price for the ENT version. Will it be released
> this year? >>
>
> No, and hopefully, but probably not.  I suspect it will be available by
> Jan/Feb of next year.
>

Tim,
   Ok, thanks for the explanation. Hopefully your ENT version won't be
royalty based like the other guy's. Smile

Dave
Fri, Sep 7 2007 6:02 AMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

Dave,

<< Ok, thanks for the explanation. Hopefully your ENT version won't be
royalty based like the other guy's. Smile>>

No, it will be pricier but still royalty-free.

--
Tim Young
Elevate Software
www.elevatesoft.com

Image