skip to Main Content

Is Rube Goldberg Gracing Your Relativity Document Review Team?

Notice: Trying to get property 'post_excerpt' of non-object in /var/www/wp-content/plugins/visual_composer/include/templates/shortcodes/vc_single_image.php on line 213

How to get the most out of your Relativity searches with speed and accuracy

Sure your eDiscovery team knows how to create saved searches in kCura’s Relativity but do they fully understand what they are doing and how a few poorly constructed searches can cause performance issues? Read on and discover the technical hows and whys with all the complexity and none of the beauty of Rube Goldberg style searching.


In their award-winning 2010 music video, the band OK Go playfully executed the ultimate modern day version of the Rube Goldberg machine.  Rube’s machines are a staple of geek America, inspiring contests, games, and museum exhibits, as well appearing in cameo roles in such movies as Robots and National Geographic’s Contraption to name a couple.


For the uninitiated, inventor and cartoonist Reuben Lucius “Rube” Goldberg (1883 – 1970) was famous for designing overly complicated machines that fixed everyday problems with wit and madness.  Even though Rube died nearly 47 years ago, chances are you may have Rube wannabes alive and well and hard at work in your kCura Relativity workspaces.

Eliminate Complicated Searches in Relativity; Minimize Performance Repercussions


No document review is complete without the clever user armed with their impossibly complex nested searches pushing the operational boundaries of SQL server.  No matter your role in the review project, poorly constructed compound searches affect you with their performance and resource hogging behavior.  Here’s how a few simple tweaks can eliminate the laboriously contrived Rube-esque saved searches hiding in your workspace.


First a Note from kCura Team’s Searching Guide

kCura’s documentation on searching explains nested searches by first laying the foundation comparison to a tree complete with metaphors for ROOT BRANCH and LEAF to better understand how to construct effective complex searches.  Chances are no one on your review team is even aware of the documentation or let alone read it.  If nested searches are to be a fact-of-life for Relativity users, we introduce the following information and tips that we’re calling “Reduce the Rube Factor” (RRF).

RRF Tip #1:  Volume, Volume, Volume


The KISS (keep it simple, stupid) principle applies – reduce the number of searches.


Without getting too far afield into a discussion of static verses dynamic searches, consider whenever possible substitution of static tagging or lists as search conditions in lieu of including nested searches in your query.  This simplification and volume limiting technique will result in faster return of results especially in very large Relativity workspaces (VLRWs).


Are any of your searches overlapping?  Are you creating multiple searches for a single field when you could have a single search querying for multiple choices for that field?   Pruning to eliminate redundant searches or combining searches will help!

Trimming Leaf and Branch Searches can speed up result displays for Root Searches


With the first level weeding completed through simplification and volume reduction, we refer you to kCura’s explanatory framework where kCura likens the search architecture to Root, Branch, and Leaf searches in offering guidance for complex saved searches (see Searching behind the scenes” – System Guides).  Fine reading for the insomniac.  Only have time for the highlights? Here are noteworthy search definitions from kCura:


  • Root: the search you’re running in Relativity.
  • Branch: a saved search that relies upon the output of a Leaf Search and is then referenced by the search you’re running (the Root Search).
  • Leaf: a saved search that does not rely on the output of another saved search but is referenced by a Branch Search.


RRF Tip #2:  Misusing “Is Like” Operator in Searches

We all have that friend or co-worker that is impossibly longwinded.  Any “Is Like” search executes just like this person, taking you all the way from the beginning of time (first record/row) up to present (last record/row).


The “Is Like” operator – an overlooked villain when allied with the Rube wannabes on your review team can bring your SQL to its knees.


Why?  Relativity has to run the query through every record in the database table without benefit of an index.  Extremely resource intensive.


Fix?  kCura recommends using the “Contains” operator rather than “Is Like” whenever possible.


So, when does “Is Like” work?  Limit to running against a subset of data; for example “Relativity Native type is like Excel” on a production set.

Did you know the “Is like” operator prevents other queries from editing the table until it completes? 

This can negatively affect performance.


Don’t believe us?  In off hours, try it for yourself.  Use “Is Like” across a heavily populated field like Control Number as we witnessed on a recent project .

RRF Tip #3:  Family Problems in Search Queries


Including relational groups (families, email threads, dupes etc.) adds run time for searches.  Use sparingly especially for lower Branch and Leaf Searches.


This is an oft-overlooked time saver by even the most careful Relativity users.  Homer Simpson says it best: “I believe that children are our future. Unless we stop them now.”

RRF Tip #4:  Sort Order


The specter of Rube haunts even the eDiscovery pros when using an unnecessarily complex sort order.  Relativity sorts by selected fields before search results display.


All that simplification and trimming up to this point is for naught if the display of Root Search results is delayed due to a complex multi-level sort.  Use an existing View containing the desired sort order.

In no circumstance should your mad scientist user be adding sort orders to Branch and Leaf Searches (their raison d’etre is simply as output feeders to the Root Search).


We wish you safe, happy, and speedy searching.





Mimi Singh is the Associate General Counsel and Director, eDiscovery Consulting.  


Terry Lundy is Evolver’s Associate Director of eDiscovery Consulting.


They provide litigation support services to Evolver’s diverse clientele on all stages of the EDRM life cycle to assist in satisfying eDiscovery obligations consistent with proportionality guidelines utilizing innovative software solutions in addition to kCura’s Relativity suite. 

Back To Top