How the console determines what objects (tables/charts) to display

Deephaven automatically displays any tables and charts added to your binding by whatever query you just ran. One consequence of this is that tables/charts that do not exist in the Groovy binding will not be displayed. If you have intermediate tables that you do not want or need to display, then assign them a type so that they are not added to the binding.

Let's take a look at a query that generates three tables:

allQuotes = db.i("MKtData", "Quotes").where("Date=currentDateNy()")
lastQuotes = allQuotes.lastBy("USym")
lastQuotesWithMid = lastQuotes.updateView("WMid=(Bid*AskSize+Ask*BidSize)/(BidSize+AskSize)")

When this query runs, tabs for "allQuotes", "lastQuotes", and "lastQuotesWithMid" will appear in the console. However, if you do not want to display "lastQuotes", you can change it to:

allQuotes = db.i("MKtData", "Quotes").where("Date=currentDateNy()")
def lastQuotes = allQuotes.lastBy("USym")
lastQuotesWithMid = lastQuotes.updateView("WMid=(Bid*AskSize+Ask*BidSize)/(BidSize+AskSize)")

In this case, "lastQuotes" is not in the binding, and it will not be visible when the script returns. "def" is Groovy's 'type' for dynamic typing outside of the binding.

Here is another version of the query:

allQuotes = db.i("MKtData", "Quotes").where("Date=currentDateNy()")
Table lastQuotes = allQuotes.lastBy("USym")
lastQuotesWithMid = lastQuotes.updateView("WMid=(Bid*AskSize+Ask*BidSize)/(BidSize+AskSize)")

"lastQuotes" is no longer in the binding, but there are still references to that table itself, as it is still feeding the "lastQuotesWithMid" table. "lastQuotes" falls between "allQuotes" and "lastQuotesWithMid" in your query graph. However, generally speaking, this does not improve memory usage or performance, since you will still have a reference to the table.

Here is the query all in one line:

lastQuotesWithMid = db.i("MKtData", "Quotes")
    .where("Date=currentDateNy()")
    .lastBy("USym")
    .updateView("WMid=(Bid*AskSize+Ask*BidSize)/(BidSize+AskSize)")

You may have fewer intermediate table objects that are visible to you at the end of the script, but the query still creates the same number of tables and does the same amount of work:

  1. get a table,
  2. filter it,
  3. look at last rows by USym, and
  4. calculate a weighted mid.

However, choosing not to display tables can make a meaningful difference if you are performing an operation in a loop. For example:

dates =  //get an array of dates
for(String date : dates) {
t = db.t("Market", "AllStockQuotes").where("Date=`$date`")
result = //run a regression, join in positions, etc.
publishVariable("result_$date", result)  //put the result in the binding as, for example,"result_2018-04-10"
}

Here, "t" and "result" are in the binding, but because they are replaced on each iteration, the tables created by previous iterations can be cleaned up. However, putting the results for each individual date in the binding with publishVariable prevents this cleanup because a brand new variable is being added to the binding on every iteration. So, an alternative to the case above is to actually write the results to another table:

db.addTablePartitionAndDefinition("mynamespace", "mytable", "Date", date, result_<date>)

This function will create a user table at "mynamespace"/"mytable", partitioned by the Date column, and then will write out the data from result_<date> for the given date.