Based on 

it looks like History.Views may not have indices or at least doesn't have a bitmap index.  If the table had a bitmap index it shouldn't take 30 seconds to count the rows. ... but maybe I'm incorrect.... seeing the query plan would have provided that insight.

You report that the now generates in 60 seconds and previously it 28 minutes for a twelve-page report.  Was the primary problem /time consumed in gathering the data or something else?

In the past, I have utilized %CSP.StreamServer to accomplish this.  While this may have a %CSP package name its perfectly usable in a ZEN context.

IRIS supports 

Create View

Create Table

Create Function

Create Query

At the same time if you have the proper IRIS license you can create analytics cubes within IRIS and as you say you can connect directly and leverage those analytics cubes.

I'm not sure when using %Library.ResultSet but there are several reasons you might want to consider using %SQL.Statement including with %SQL.Statement you can use the instance method %GetImplementationDetails which should provide you with what you are looking for.

and since others will view this we really should include in the method GetPropertiesFromRelationship the call to %UnSwizzleAt. I don't think in the above example it would improve performance in a positive meaningful way but when you encounter large relationship graphs this can be very important.

how about adding a note about the fact that each index implements a 

IndexNameExists(value,.tId)

method and can be used to quickly determine if a value exists in the index?

how about adding a note about the fact that each index implements a 

IndexNameExists(value,.tId)

method and can be used to quickly determine if a value exists in the index?

You might also find some relief by querying %Dictionary.MethodDefinition WHERE SQLProc=1 or %Dictionary.QueryDefinition.  If it's a really old version you might look in %Library schema.

This article refers to https://github.com/es-comunidad-intersystems/IRIS-in-Astronomy but when I tried going there you get a 404 Page not found.  Maybe the repo is not public?

You can look at the contents of zenutils.js to see the actual details of the zen(id) function.

The IDX system is oftentimes partitioned by Group(GRP).   Additionally I suspect the 86M records do not represent invoices for a single year.  Using %SYSTEM.WorkMgr you could break the job up in to smaller jobs by GRP and or InvCrePd or YEAR(BAR.Invoice.SerDt) 

Some of the reasons why I focus on utilizing class queries include

• Studio and other editors are much better at providing coloring/syntax checking vs a strategy of setting a tSQL string as some arbitrary SQL statement
• As mentioned in the original post it provides the separation that allows for easy re-use and testing.  If I have a class query I can decide to allow it to be reflected as a stored procedure, I can expose it to ZEN reports, ODBC/JDBC, JSON projection, %XML.DataSet, I can use it to satisfy a control in ZEN that allows for binding to a class query,  as well as others.  Basically, it provides for great separation.
• I also like the idea of considering writing the statement using SQL as %Query.  If for some reason I run into performance issues that I cannot overcome I can change the implementation to %SQLQuery and implement COS code, the calling application would see the improved performance but does not have to understand the internal implementation.  However, I've only done this on extremely rare occasions.
• I think one of the most important aspects of SQL to always read the query plan, it's there where you can understand what the optimizer is going to do.  I care all about the query plan and almost always validate what it reports.  Having a class query allows for easy Show Plan examination whereas it's generally hard to do if you take the approach of setting a tSQL string(sometimes with concatenation over several lines).

Class Queries are really worth investing in IMHO.

I used to work at IDX under the division that produced what was called IDX Flowcast.  IDX Flowcast is a practice management system for large practice/academic medical centers.  Groupcast on the other hand was for the small practice environment, I don't recall the exact # of doctors as the threshold cutoff.  I do not believe Groupcast is based on Intersystems Cache, but I could be incorrect.  If the system is Flowcast aka GE Centricity Business, then most all of the data is exposed via Cache classes that are based on %SQLStorage and hence would be exposed via any SQL client interface connecting to Flowcast/GE Centricity Business using ODBC/JDBC.

Not to my knowledge.  While there is a global node in the storage map that is used to get the next available Id this would only work on tables/objects based on a single integer id.  At the same time, this is the next available Id and does not account for physical deletes that may have occurred, ie the next Id might be = 101 but you may have fewer than 100 rows/objects as some may have been deleted.  The simplest way to accomplish this would then to perform a SELECT COUNT(*) FROM TableName.  If the table implements this bitmap indices this should be ms.  If you don't get the performance you want you might consider adding %PARALLEL to the FROM clause and let the optimizer decide if it makes sense to split the job.

You wrote

BUT the server is 6 times faster if OpenId replaced with simple read of a large global (s p=^someLargeGlobal). Any ideas what makes OpenId so slow only on the server?

while not specifically answering your general question, note that opening an object is very different than 

Set p=^SomeLargeGlobal.

When you call %OpenId

1. Concurrency is checked.  While not widely used there is a second parameter to the %OpenId method that controls the behavior of concurrency  and you may want to consider providing the desired concurrency option.  In the past if I was not concerned with concurrency as I just wanted to read data I would use option 0.
2. Each and every property defined in your class is loaded into memory, ie the data is read from the global and then the individual properties are set accordingly.  Depending on how complex your class is the difference between 

Set p=^SomeLargeGlobal 

and %OpenId can be quite different, at least academically.

If your class as relationships and/or serial/embedded classes I do not believe those properties are fully loaded into memory, but I could be incorrect.

In practice, if I need an object I use objects, if I need only a small part of the object/row I'll use embedded SQL for better performance.

Again this does not specifically answer your general question but I think it is useful to understand what %OpenId does and why it's not the same as 

Set p=^SomeLargeGlobal.

Depending on what you exactly mean by the same structure you consider using a Serial Class definition that is embedded in both of your classes.  However, if the structure is stored across several global nodes I do not think you could use this as the Serial class would define the pieces(whether delimited or $ListBuild pieces) and then the serial property is described in your 2 classes to occupy a single node.

You could also consider defining a single abstract class that describes the properties and have your 2 classes inherit from your abstract class.

With regards to having a variable defining the data location I suspect that it may not be doable, even if it were I don't see how it improves things in a significant way.

I would be interested in the English version as well.

I'm generally looking at the query plans either from the SMP or from the context menu in Studio while writing class queries/embedded sql statements.

One issue that I've seen is that while the query plan is very good, an in many cases better than what other dbms's provide, when a sub-query is part of your query statement it's not exactly clear when it is utilized in the query plan.  For example, I have this query plan

I cannot tell with 100% certainty where "subquery" is called.

While the cost may be high, the real question might be better focused on the performance.  Relative cost is just that, relative. 

What does the rest of the query look like?

What is the time to first row, time for all of the data? 

Does the query plan utilize the index on the StartDate column?