Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Enhancement Requests and Suggestions » View Thread |
Messages 1 to 6 of 6 total |
EDB Mgr suggestions |
Sat, Sep 1 2007 12:20 AM | Permanent 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 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 PM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 PM | Permanent 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. Dave |
Fri, Sep 7 2007 6:02 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Dave,
<< Ok, thanks for the explanation. Hopefully your ENT version won't be royalty based like the other guy's. >> No, it will be pricier but still royalty-free. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Wednesday, April 24, 2024 at 11:07 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |