HANA Tech Con 2025

PPT-less Demo*

You Think You’re Optimizing? HANA Thinks Otherwise.

Jörg Brandeis

*This is Marp - Not Powerpoint

Jörg Brandeis

Roles

  • Trainer for SAP Development topics
  • Managing Director of Brandeis Consulting GmbH
  • BW/4HANA Developer & Consultant
  • Author of the Book SQLScript für/for SAP HANA

CV

  • Carpentry apprenticeship [1996-1999]
  • Dipl. Wirtschaftsinformatiker, Uni Mannheim [1999-2004]
  • Intern, developer, Head of ABAP Development at zetVisions AG in Heidelberg [2002-2015]
  • Freelancer [2015]
  • Founding of Brandeis Consulting GmbH [2020]

Social Media

(C) Brandeis Consulting

Brandeis Consulting GmbH

Training for modern SAP development

  • SQLScript for BW-Consultants
  • BW/4HANA Delta Training
  • CDS ABAP - Focus on Analytics or S/4
  • ABAP RESTFul Application Programming Model (RAP)
  • HANA Calculation Views
  • Firoi Elements
  • SAPUI5 Basics
  • Eclipse ADT
  • ABAP Cloud & Modern ABAP

Coaching

Development Projects

(C) Brandeis Consulting

The Scenario

(C) Brandeis Consulting

Two Codings to compare

DO BEGIN
    RelevantTasks =
        SELECT id, assignee, project
        FROM tasks;

    TasksWithAssignee =
        SELECT rt.*,
               assignee.firstname,
               assignee.lastname
        FROM :RelevantTasks AS rt
        LEFT OUTER JOIN users AS assignee
                     ON rt.assignee = assignee.id;

    TasksAssigneeProjects =
        SELECT twa.*,
               p.id AS projektid,
               p.project_manager
        FROM :TasksWithAssignee AS twa
        LEFT OUTER JOIN projects AS p
                     ON twa.project = p.id;

    ResultSet =
        SELECT tap.*,
               pm.firstname AS PL_firstname,
               pm.lastname AS PL_surname
        FROM :TasksAssigneeProjects AS tap
        LEFT OUTER JOIN users AS pm
                     ON pm.id = tap.project_manager;

    SELECT *
    FROM :ResultSet;

END;
DO BEGIN
  SELECT  task.id,
          task.assignee,
          task.project,
          assignee.firstname AS as_firstname,
          assignee.lastname  AS as_surname,
          project.id         AS p_id,
          pm.id              AS pl_id,
          pm.firstname       AS pm_firstname,
          pm.lastname        AS pm_lastname

    FROM tasks            AS task

    LEFT OUTER JOIN users AS assignee
    ON task.assignee = assignee.id

    LEFT OUTER JOIN projects AS project
    ON task.project     = project.id

    LEFT OUTER JOIN users AS pm
    ON project.project_manager = pm.id     ;
END;

Which one is better to debug? To Read?
Which one will use less memory? Is faster?

(C) Brandeis Consulting

PPT-less Demo

Live on HANA

(C) Brandeis Consulting

Conclusion

  • Write readable code that your colleagues understand
  • Only optimise performance if there is a problem
  • Analyse the execution plan before you optimise

Some Quotes about this topic

Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%.
( Donald Knuth, Structured Programming with go to Statements, 1974 )

Rules of Optimization:
Rule 1: Don’t do it.
Rule 2 (for experts only): Don’t do it yet.

( M.A. Jackson )

More computing sins are committed in the name of efficiency (without necessarily achieving it) than for any other single reason – including blind stupidity.
( W.A. Wulf )

(C) Brandeis Consulting

Backup Slides

(C) Brandeis Consulting

Story

  • Two Queries, same Plan
  • Add a where condition - See if it is pushed to the DB-Table
  • Change the Condition to status = 1
    ==> Execution plan switches - Why?
  • Change to value 2
    ==> Execution plan swiches again!!!

==> It is not under our Control

==> We should not try to write code that is optimized.

(C) Brandeis Consulting

Both lead to the very same execution plan!

(C) Brandeis Consulting

Two similar Queries

DO BEGIN
  SELECT  task.id,
          task.assignee,
          task.project,
          assignee.firstname AS as_firstname,
          assignee.lastname  AS as_surname,
          project.id         AS p_id,
          pm.id              AS pl_id,
          pm.firstname       AS pm_firstname,
          pm.lastname        AS pm_lastname

  FROM tasks            AS task

  LEFT OUTER JOIN users AS assignee
  ON task.assignee = assignee.id

  LEFT OUTER JOIN projects AS project
  ON task.project     = project.id

  LEFT OUTER JOIN users AS pm
  ON project.project_manager = pm.id

  where task.status = 2   ;
END;
DO BEGIN
  SELECT  task.id,
          task.assignee,
          task.project,
          assignee.firstname AS as_firstname,
          assignee.lastname  AS as_surname,
          project.id         AS p_id,
          pm.id              AS pl_id,
          pm.firstname       AS pm_firstname,
          pm.lastname        AS pm_lastname

  FROM tasks            AS task

  LEFT OUTER JOIN users AS assignee
  ON task.assignee = assignee.id

  LEFT OUTER JOIN projects AS project
  ON task.project     = project.id

  LEFT OUTER JOIN users AS pm
  ON project.project_manager = pm.id

  where task.status = 1   ;
END;
(C) Brandeis Consulting

Demo 2

Live on HANA

(C) Brandeis Consulting

The two approaches lead to an execution plan on different engines

(C) Brandeis Consulting

An other example

Once an Oracle Expert told me, that the NOT EXISTS predicate is slow and should be avoided. A LEFT OUTER JOINwith filtering on the NULL-Values is much faster.

We tried both approaches, but the result is the 100% exact same logical execution plan on SAP HANA!

select *
  from users as u
  where not exists (select *
                      from tasks as t
                     where u.id = t.assignee );
select u.*
  from users as u
  left outer join tasks as t
  on u.id = t.assignee
  where t.id is null;

The first statment is much more readable, because it is obvious that

  • I am interested in data of the users table
  • The data should be filtered
(C) Brandeis Consulting

Conclusion

  • It's only important, what result set you are describing with your code
  • For the HANA Database it is less important, how you describe the Result
  • You can't control the optimizer by writing code in a certain way
(C) Brandeis Consulting

Readability and performance are not contradictions

(C) Brandeis Consulting

Thank You for your attention

(C) Brandeis Consulting