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.

In the rule you should be able to have an expression with 

Stream.Read(some number of character.. you might consider 3200000)  

to get the first X characters of the stream content... of course assuming the thing you are searching for can be found in that string.

My experience is the developer room offers the best opportunity to interact with the InterSystems developers, this is the most rewarding part.