--- > What I had in mind was a node is a fixed size > structure that contains a > pointer (or reference) to table data which may be in
Yep. I pretty much agree with the priciple. I built the BLinkTree to be a sorted map of elements to longs. The longs can be references into just about any kind of data structure that hold actual rows. > What I envisage is when we build the result set we > build an index (could be > an aggregate index) that will be used for sorting > it. This way we can also > get the result set to contain unique values only to > deal deal with > subqueries such as SELECT .. WHERE X IN (SELECT > ...). ok > > Rows of the resut set are stored in a separate nio > file. yes > > The index is built fully then truncated if necessary > (SELECT LIMIT N M ...). This is what I was thinking of as a bottle neck. The problem is the latency in the disk reads. For very large tables that are bigger then the cache, you may have the flush the cach several times. A good portion of the time, the system may be idle while you wait for the data to page in. Building a small result set and then returning may increase responsiveness of the system. The thread calling the query can do some work while the rest of the result set is generated. But like I said, this is a more complicated system. ===== 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
