>>Furthermore, all of these tests must be over a LAN with large tables.
>
>No reason to raise such a qualification that late in the argument;-)))
>
>With "my" app that was not the case: munging across the fastest disks available, also with special code in place to put index and data file on separate physical platters for the most used write heavy files (some of them on a real RAM disc, was before SSD became common place, with table based lookup of where for what configuration the index file had to be opened). Also some of the data files were packed on disk, others not: division mostly due to R/W differences in typical usage during the runs.
>
>Numbers showed better perf with A FEW more binary indices.

Unless we're looking at the same code, tables, and server, all of these discussions are pointless. The reason being - others misinterpret things. As I said, if there is a big table with a simple SELECT COUNT(*) FROM TABLE and set deleted is on, that count will be fast because the count really says COUNT FOR NOT DELETED(). With that tag, that count will not count anything. It will look at the number of not deleted entries in the index tag. That's comparing apples to oranges. It's a cheat.