Excellent work.  I was just search for this yesterday and this morning saw this.  I gave it a spin and it works perfectly.

One aspect that I think is not always appreciated is how locking is happening automatically.  For example, 

1. the %OpenId method when used in Objects has a second parameter that is not always utilized or thought about.  The second parameter is the concurrency parameter.  I think of applications as plenty of locations where reads are done and a single(small number of places) where %Save is done.  With this in mind do you really need a lock of some kind in the place where reads are done.  You may feel like they do need locks which is fine, just understand that calling %OpenId will use the default concurency option and this may acquire some form of a lock.  Now the other aspect of this is %OpenId returns tSC by reference.  How many people call %OpenId and never check the value of tSC.  This could come back with an error %Status if for example you didnt specifiy the concurrency option and some other process had an Exclusive Lock on the record you are attempting to Open
2. SQL statements like INSERT, UPDATE, DELETE will by default acquire locks on the rows that it is impacting.  You can use the %NOLOCK keyword to tell the SQL engine to not lock but that is on you to add.  If you have a single SQL statement like DELETE FROM Table1 WHERE NOT EXISTS (SELECT * FROM Table2) this statement is atomic, which means among other things
   1. all of the deletes on the rows are journalled
   2. all of the rows that are being deleted will be locked.  At some point lock escalation will take place and the table will be locked.

TLDR .. know that locking is happening when using Objects and SQL and use accordingly.

This all starts by examinging the query plans and undestanding what the Query plan is telling us.  With large data sets a bitmap index is generally much better for performance than a traditional index for columns that 

1. have a small number of distinct values, the general recommendation is when the column has less than 10,000 distinct values.  For example MRN which should generally be thought of as unique, or StreetAddress are not good candidates for bitmap indices as they have thousands of distinct values.  On the other hand columns like Status, InsertDate, Code etc are often times good candidates for bitmap indices.  Query plans are available from the Show Plan button when writing a SQL Statement and also from the SQL Statements tab from System Explorer->SQL.  This tab allow you to sort the columns and I find it useful to look at 
   1. statements that are run frequently
   2. statement that have a lengthy Average Time

In System Admin->Configuration->SQL and Object Settings->SQL do you have "Execute Queries in a single process" checked.  If so, you may want to consider unchecking it.

When defining bitmap indices it is better to create a bitmap index on a single column and have multiple indices over creating a bitmap index that is based on several columns.  The optimizer, query engine will combine individual indexes when needed whereas if you have a bitmap index on A,B and you query only has a condition on B the index may not be selected.  Having Index A on A and Index B on B will combine indices when you have conditions on A and B but will also be able to use the B index if you only have a condition on B.

Relative Cost is just that..its best thought of the number for your SQL statement.  If you adjust your statement and the cost increases and you cannot explain why you might want to retrace your steps.  But the cost is just for your single statement.. you cant compare the cost between a Statement that query Table A against a SQL Statement for Table B.

Have you tuned your tabled and gathered statistics so the query engine has information about your tables?

What kind of large volume do you have?

and again, everything is revealed in the Show Plan.