Location Hash Values

The Location Hash Value (LHV) feature was introduced in Kognitio Version 8.1.0 to allow some queries to be run in a single ramstore. Earlier versions of Kognitio only support fully parallelized query execution, i.e. all ramstores take part in all queries.

The LHV feature works by looking at filters applied to the hash column of a Kognitio view or table image and using these to deduce when the whole query can be serviced by a single ramstore.

For example if you have a hashed table:

CREATE TABLE t (f1 int,
                f2 varchar)
HASHED (f1);

The table uses a hash function on f1 to map rows into ramstores. So if the user runs a query like:

SELECT *
FROM t
WHERE f1 = 7;

Then Kognitio knows to only use the ramstore that the value 7 hashes to. Kognitio hashes the number 7 to make the LHV and then use this to direct the query to the single ramstore.

This feature greatly improves query throughput when Kognitio is running a large number of highly selective queries concurrently. By using LHV, Kognitio eliminates the need to set up and tear down a lot of operations which aren’t going to do anything.

In Kognitio version 8.2.0 onwards this feature has been extended via the asymmetric query enhancements to allow multiple LHVs per query. This means that Kognitio can improve performance in queries when the filter maps to more than one ramstore, for example:

SELECT *
FROM t
WHERE f1 in (1, 2, 3, 4, 5, 6, 7);

In this example up to 7 LHVs would be produced. Note during hashing some values may create duplicate LHVs. The query would run on up to 7 ramstores.

In Kognitio version 8.1.0 it was necessary to denormalise images to make use of LHVs These can now be run using normalised images and joins and still get the scale-out and concurrency benefits of LHV.

From Kognitio version 8.2.0 onwards the LHV feature is able to infer LHV values from joins to small or highly filtered tables or views. This allows the use of multiple LHV values during selectivity gathering and other parts of query compilation. This means that Kognitio never performs a full non-LHV scan of a table if there are valid LHV extractions in the query. For example:

CREATE VIEW IMAGE fact HASHED (fk);

SELECT COUNT(*)
FROM fact, dim
WHERE fk = dim_pk
AND dim.name in ('a', 'b', 'c', 'd', 'e', 'f');

In this case Kognitio will extract the dim_pk values matching the filters, make LHV values from those and apply those values when selecting from the ‘fact’ table.

LHV optimisations are on by default. To make use of these simply hash the image on a column which will be filtered using constants or values derived from a join to a lookup table (the lookup table should be replicated for best performance).

The LHV feature can be disabled by setting the runtime parameter ai_auto_lhv to 0 in the config file or at the global, user or session level at runtime. The default value of ai_auto_lhv is 1.