|Subject||Re: Performance of Firebird vs. other DBMS|
--- In email@example.com, "johnson_dave2003" wrote:
> > Please bear with me, I still fail to grasp it.Thank you for your patience, I understand it now.
> When looking for max on an ascending _unidirectional_ index, since
> you do not know which of the rows are visible, you must effectively
> do a table space scan to find the guaranteed max. Your most likely
> candidate is the last row that you hit. Since you must hit the row
> itself, not only the index entry, your I/O is enormously multiplied
> because you must hit every row, keeping a reference to the last row
> that met the criterion. Assuming an average sized table with
> 1,000,000 rows, you are talking about (index page count) +
> (1,000,000) I/O's to identify the max against an ascending index.
> Using a descending index means that the most likely candidate is the
> your first candidate you hit. If the candidate is not visible you
> just move to the next entry. You are typically talking about 2
> I/O's (1 index + 1 data) to identify the max row in a descending
> This is magnified in the generational architecture, but also true
> for locking architecture such as DB2.