Performance Issues |
Phil Van Hout |
2007-05-11 16:20:33 |
We currently are running v2.1 of your JDBC DBF driver with FoxPro and are seeing performance issue with query times. I am trying to get the record set size to pass along to see if we are running up against limitations in the driver. Are there performance enhancements in the newer v3.0?
Thanks,
Phil
|
Re:Performance Issues |
HXTT Support |
2007-05-11 17:53:50 |
You should use the latest pacakge. Some modifications are listed at here.
|
Re:Re:Performance Issues |
HXTT Support |
2007-05-11 17:55:02 |
> A little more info: The two tables we are primarily dealing with have 1.4
> million and 3.1 million records.
> We are trying to get a copy of it to see what indexing is being done.
> Do you forsee this as problem?
What's your sql samples?
|
Re:Re:Re:Performance Issues |
Phil Van Hout |
2007-05-13 12:52:49 |
Do we have rights to download the newer version?
|
Re:Re:Re:Re:Performance Issues |
HXTT Support |
2007-05-14 19:00:29 |
Changed. Now you can download the latest package.
|
Re:Re:Re:Re:Re:Performance Issues |
Matt Gollob |
2007-06-01 08:47:54 |
We are currently trying to commit a single record update to a table containing 3 million records and 6 indexes. We are using a sql "executeUpdate" prepared statement containing 14 parameters.
The issue that we are having is with the time that it takes to update the record. It often takes up to a minute to update which by that point the client has already timed out.
Are there any know issues with this size of database table or amount of indexes? Do you have any suggestions as to how we can improve performance? Thanks so much for the help.
|
Re:Re:Re:Re:Re:Performance Issues |
Matt Gollob |
2007-06-01 08:51:07 |
We are currently trying to commit a single record update to a table containing 3 million records and 6 indexes. We are using a sql "executeUpdate" prepared statement containing 14 parameters.
The issue that we are having is with the time that it takes to update the record. It often takes up to a minute to update which by that point the client has already timed out.
Are there any know issues with this size of database table or amount of indexes? Do you have any suggestions as to how we can improve performance? Thanks so much for the help.
|
Re:Re:Re:Re:Re:Re:Re:Performance Issues |
HXTT Support |
2007-06-01 08:59:40 |
What's your sql? What're your 6 index expression?
|
Re:Re:Re:Re:Re:Re:Re:Re:Performance Issues |
Matt Gollob |
2007-06-01 09:22:43 |
Here is the sql statement:
PreparedStatement sql = _db.prepareStatement("update nwcntmas set intraconum = ?, wstcategs = ?, cntnruom = ?, quantity = ?"
+ ", uom = ?, [is] = ?, persol = ?, initloc = ?, s = ?, drumcredit = ?, status = ?, barcode = ?, Beguser = ? "
+ " where container = ?");
The six index expressions are:
container, cntnrsrc+container, initdate, tracking, intraconum, barcode+container
Thanks
|
Re:Re:Re:Re:Re:Re:Re:Re:Performance Issues |
HXTT Support |
2007-06-01 17:31:04 |
>a table containing 3 million records and 6 indexes.
>It often takes up to a minute to update which by that point the client
>has already timed out.
It will use container index to find what row need to be upadted, but all of six index files will be retrieved and updated. Please tell us that index file size, and whether most values of one indexed expression is same.
|
Re:Re:Re:Re:Re:Re:Re:Re:Performance Issues |
Matt Gollob |
2007-06-04 08:33:05 |
The index file size is 175 MB. Most of the values of the indexed expressions are not the same. Thanks.
|
Re:Re:Re:Re:Re:Re:Re:Re:Performance Issues |
HXTT Support |
2007-06-04 09:21:14 |
>>container, cntnrsrc+container, initdate, tracking, intraconum, barcode+container
>The index file size is 175 MB. Most of the values of the indexed expressions are
> not the same.
It seems that it spent too much time on maintained your index file. First, backup your table and index file. Secondly, try to run "reindex all on yourtable" to aovid possible unbalanced index tree issue.
>container, cntnrsrc+container, initdate, tracking, intraconum, barcode+container
What're the column lengthes of container, cntnrsrc, initdate, tracking, intraconum, and barcode. If there's some longer varchar column, it will use more time and space to index. If your sql hasn't cntnrsrc+container, or barcode+container in where clause, you can consider removing that index.
|