Hello @rbygrave ,

our DB2 customer and his DBAs gave us tips on how to improve DB2 migrations.
We had the problem that the application became very slow after an update. The reason was that we were running reorgs on large tables but not using runstats afterwards.
Runstats helps the query optimizer build faster queries based on statistics.
Documentation on runstats: https://www.ibm.com/docs/en/db2/11.5.x?topic=commands-runstats

The DBAs also expected more performant reorg commands.

During reorg, they expect the following additional arguments: reorg table <tablename> use tempspace1 resetdictionary

• use tempspace1 prevents unwanted bloat of regular tablespaces

Our first approach to the problem would be the following:

• We extend reorg with the reorgArgs placeholder and set use tempspace1 resetdictionary as the runPlaceholder. However, this would be a breaking change for other DB2 ebean users. So we could make it activatable with a parameter.
• When you need runstats is a bit complex (certainly after reorgs, when new indexes are created, etc.), so we decided to run runstats on all tables after each release.
  Otherwise, we could have ebean insert comments in the right places indicating when runstats are needed, and the application takes care of running runstats with every application update.

We also received special commands for runstats that we should execute:
runstats on table <tablename> use profile

The call fails if the statistics profile is (still) missing.
As a fallback, the call must be made as follows:
runstats on table <tablename> and indexes all

Could you please give us feedback on whether we're moving in the right direction to execute special commands?

We were also thinking that mariaDb, or SQL Server, might also need statistics updates from time to time, not just DB2.