Hi all, this is an interesting discussion. Just wanted to jump in here with a little bit of feedback and some observations from the system I am working on.
I did a similar test as Leonid regarding indices on a table with no keys, and had a volume of around 700,000 records.
SELECT *
FROM "MOLJUS02"."MARA"
WHERE "MATNR" = 'TRM108274';
First run time was about 75ms, but subsequent executions were around 8ms
CREATE INDEX IDX_MOLJUS02_MARA_MATNR on "MOLJUS02"."MARA" ("MATNR");
SELECT *
FROM "MOLJUS02"."MARA"
WHERE "MATNR" = 'TRM108274';
First run time was about 75ms, but subsequent executions were around 8ms
So what I observed is that the runtime was not improved at all after introducing an index.
I decided to take this a step further to dive into a more detailed testing. My interest here is because in the system I am working on now, there are a lot of tables that are non SLT-delivered. These also happen not to have any primary keys defined, and therefore could not make use of the Inverted Index mentioned in this thread.
Aside from the bad design principle of not having keys defined to ensure data contstraints, I was trying to reach the conclusion to the answer of "do primary keys speed up queries", as seen from a pure SELECT perspective as well as within an Analytic View (star schema) perspective.
Purpose: Determine efficiencies gained in performance by using table with primary keys defined
Hypothesis: Tables with primary keys will perform better with SELECT and JOIN operations due to the use of the inverted index.
Testing methodology
- Create copies of two sets of tables, using SLT delivered tables as template. Remove the keys of the tables and insert the same data.
- Ensure that the tables are merged and inverted indices are present on the tables with keys
- Perform a SELECT test on table with single key choosing a single or IN list of materials and compare results
- Perform a SELECT test on table with multi key choosing a single column to apply filter on material and compare results
- Create attribute views on all 4 of the tables created in step 1, ensuring primary keys match to Key Attributes.
- Create a basic analytical view on a large fact that consumes the attribute views in step 5. All joins are defined as left outer with a n:1 relationship.
- Perform a SELECT test on the analytical view using highly aggregated columns from attribute views, forcing a join.
- Perform a SELECT test on the analytical view using the most detailed grain in the attribute views, forcing a join.
- Perform a SELECT test on the analytical view using the most detailed grain in the attribute views, forcing a join and applying a single MATERIAL filter to the dimension.
- Each test above is executed multiple times and average run times are shown.
Table Sizes
MARA (keys MANDT/MATNR) – 703,000
KNVV (keys MADNT, KUNNR, VKORG, SPART, VTWEG) – 726,000
CE12000 (Fact – many keys) – 1.1 billion records
SELECT Results
Query | With Keys | No Keys | Variance from keys to non-keys |
MARA (single column key) | 6.6ms | 11ms | +5.4ms (81%) |
KNVV (multi column key) | 4ms | 5ms | +1ms (25%) |
KNVV (smaller query set) | 2ms | 3ms | +1ms (33%) |
Model Results
Dimension and query | With Keys | No Keys | Variance from keys to non-keys |
MARA - aggregated | 784ms | 823ms | +39ms (5%) |
MARA – detailed | 5,497ms | 5,427ms | -70ms (~) |
KNVV – aggregated | 780ms | 750ms | -30ms (3.85%) |
KNVV - detailed | 1,685ms | 1,682ms | -2ms (~) |
| MARA - filter applied | 249ms | 246ms | -3ms (~) |
So analyzing what I have seen, the conclusion that I have come to is that the presence of a primary key and thus the inverted index actually had no effect on the runtimes when compared to the equivalent data structures that had no keys/indices defined.
Any thoughts on these results or ways to point out how it could be done better? Ultimate goal is performance optimization, and right now this (keys and indices) doesn't look like a very effective angle for improving Analytic View performance.
Regards,
Justin