Performance
HANA performance is usually excellent by design, but realising it requires good modeling and SQL: pushing computation down, avoiding row-by-row processing, and writing efficient views. Poorly-written logic can be slow even on HANA.
Layer and simplify calculation/CDS views, push filters/aggregation down, and minimise data movement.
- HANA is fast because it is in-memory and columnar, so set-based scans and aggregations fly.
- Use HANA’s tools, the SQL plan visualizer (Plan Viz) and Explain Plan to see how a query executes, plus the HANA cockpit for…
- Row-by-row processing (loops) instead of set operations.
- Watch out: Row loops instead of set-based logic.
What makes HANA fast, and how to keep it
HANA is fast because it is in-memory and columnar, so set-based scans and aggregations fly. You keep it fast by working with the grain: filter and aggregate in the database, avoid moving large data sets out, and prefer set-based SQL/CDS over procedural row loops.
Where performance is lost
- Row-by-row processing (loops) instead of set operations.
- Pulling large data to the app tier instead of pushing logic down.
- Expensive joins / late aggregation in poorly-designed views.
- Missing filters scanning more than needed.
Analysing performance
Use HANA’s tools, the SQL plan visualizer (Plan Viz) and Explain Plan to see how a query executes, plus the HANA cockpit for system-level monitoring. These show where time and memory go so you optimise the real bottleneck.
Modeling for performance
Layer and simplify calculation/CDS views, push filters/aggregation down, and minimise data movement. Because the engine is so fast, most remaining performance problems are design problems, solvable by better models and SQL.
Common pitfalls
- Row loops instead of set-based logic.
- Late/absent filtering and aggregation.
- Not using Plan Viz/Explain to find the real issue.