On Thursday 28 June 2007 20:40:04 andrew wrote: Hi Drew,
> Well, no. I am talking about using the search function. That is not SQL > based, instead it iterates over the result set looking for the first > match, and it is all on the client side. > > Here is a specific example. I have a table that consists of 21 fields, > all of type integer or double. The table has 10,000 records. This is a > HSQL embedded database, it is running under XP on an AMD 3300+ processor > and 640Meg Ram. The table has a primary key field of type integer, and > is fully packed ( meaning there are keys from 1 - 19,999 ). > > I open that table in a data view and place my cursor in the PK field. I > then open the search box ( click on the binoculars ) and enter a search > criteria of 2000. Now what would be an acceptable time for that search > to find a match - I'm not sure, but I am relatively sure that what I get > is not an acceptable time - on average 74 Seconds. Tell me about it :-( This problem has existed for as long as I can recall, irrespective of the db. I've had this with DBFs, mysql, HSQLDB, so the problem is definitely with OOo or the way that it executes the search function. The DBF that I used to use for my addressbook/contacts was originally created in Lotus Approach. I then migrated it to StarOffice and from there to OOo, so it's roughly about 10 years old. It hasn't been fed with data for a while because I switched to mysql about 5 years ago. We have a similar issue with another db in which the users are currently forced to filter their data in order to get acceptable performance, but as you said, this then forbids any browsing outside of the filtered resultset, which is something they could do with their previous db, a MacOS FileMaker Pro db. > > If I use the standard filter this time drops to under 2 seconds. That is > most assuredly acceptable, and yes that was done with SQL commands. The > problem is, this is a desktop database and many of the users want the > ability to browse the adjacent records after the search. In other words > they did not want to filter the result set at all, they wanted a search > function on the current result set. To add to the problem is the > behavior of removing the filter - the result set is reloaded and the > record pointer placed back to the first record. > If you're looking for performance data with HSQLDB, for example in copying from Calc to HSQLDB, you should search IssueTracker for stuff put up by Tony Galmiche who did some performance testing on early versions of OOo 2.0. I assume that these issues have either been marked as INVALID, RESOLVED or OOoLater due to resource constraints. Alex --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
