Hbase doesn't really have a lot of flexibility in how it does a query. A get is a get.
A scan is a scan. A filtered scan is a scan. There might be a few diagnostics that would tell you how many records were rejected in a scan or which coprocessors executed or which column families were used, but there isn't a lot of magic optimization going on. This is very different from SQL where your query doesn't specify what actually happens very directly. On Tue, Jul 26, 2011 at 11:10 PM, Steinmaurer Thomas < thomas.steinmau...@scch.at> wrote: > Hello, > > > > we have a three part row-key taking into account that the first part is > important for distribution/partitioning when the system grows. Depending > on the access pattern, we might be in a situation to use e.g. RegEx > filters on rowkeys. I wonder if there is some kind of an execution plan > (as known in RDBMS) when running a HBase query to better understand how > HBase processes the query and what execution path it takes to generate > the result set. > > > > Or is this a complete different thinking? > > > > Thanks, > > Thomas > > > >
