see below > In my view, the cases where fine-grained locks can > make a difference are > very few. But since you've been working with
The only place I can think of is a multi processor system, a huge dataset and shared memory. This is not our use case. HSQL seems to get used on single processor systems with small to medium db. Ok here is what I will do. I will put the code up to sourceforge so you guys can check it out. Maybe you will spot a way to make fine grain fast. But I will change my assumptions to that only a single thread is working on the tables for that query. I will switch over to using B-Tree rather then B-Link and then should make make my code faster and simpler. > process is probably on average a 1000 times that of > 20 years ago (using the > same proportion of total Primary storage available). > Could this influence > our approach? For example, if a node takes 16 bytes > then we can store the > index for a million rows in 16MB of memory. On a Small nodes may be faster if you know the table will always be small and there are a lot of inserts and delete. Search may be little slower. If the table ever gets big, then you will have to work out of disk. Then big nodes(100 to 500 elements) work best. It would not be very hard to make the size of the node stored with the index. Then the size can be tuned depending on your use case. More RAM mostly helps the Result sets and small data sets IMHO. A good cache scheme will just naturally take all the room it is given and then live in that area. > Also something to bear in mind is we need on the fly > generation of indexes > for result sets. Currently result sets are held Ok. Should not really be a problem. A temp table should probably just act like a regular table anyway. Inserts into index are sorted. Here is an idea....how can we hide disk access? Do you generate the entire result set before you return to query? What if the result set is huge. Even big enough that it exceeds RAM.. How about a result set is only partially generated? Get all the rows you can get without paging to disk and then return. A second thread could then work in the backgound and 'pump' the result set as more of the query tables page in. The ResultSet would act more like a queue, with the 'pump' thread enqueue items as they page in from disk and the ResultSet.get() doing dequeue. There are some query this would not work, such as sorted queries or ones with min(), max(), sum()... but for many it would be ok I think.. This a complicated system..... Another problem is what happens if a second write query alters the table before the full result is read. The result could be invalidated in that case I suppose. Or do we use transactions to handle that? Just thinking... Karl ===== Karl Meissner ........................................................... : Meissner Software Development, LLC : : "Software development and project management services." : : http://meissner.v0.net/resume.htm : ........................................................... __________________________________________________ Do You Yahoo!? Yahoo! Games - play chess, backgammon, pool and more http://games.yahoo.com/ _______________________________________________ hsqldb-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/hsqldb-developers
