Thank You Ann!

The only way to get better info than this is to go through the code, and your explanation is much faster to read and more to the point.

For my purposes, it is definitely not worth the amount of effort that it sounds like it would be to work out the optimizations I was considering. I will accept this as a design tradeoff in the DBMS'. These do not impact my particular application - only my assumptions/knowledge of how Firebird internals work has changed so far.

I was presuming on a one-way index system, such as I am most familiar with in DB2 - i.e. there would be no "right hand pointers".to work with.

In the light of your clarification of how active transactions are handled, the presence or absence of a buffer pool would impact the hypothesized optimization of the max/min operators using my approach, making it either straightforward or impossible.

Does Firebird support a concept analogous to the buffer pool in DB2? In DB2, as long as a page is in the buffer pool there is no physical I/O against transactions involving that page, except possibly the initial read to the buffer pool. The commit to physical storage (as opposed to the transaction commit) generally occurs in a separate thread from the application transaction processing, freeing the application from the I/O performance constraints most of the time.


[Non-text portions of this message have been removed]