Hyper Queries Using High CPU After Upgrade to Tableau Server 2022.1.7 or Later Releases

Published: 10 Nov 2022
Last Modified Date: 21 Nov 2022


After upgrading to Tableau Server starting with 2022.1.7 (see Environment section for all affected versions), high sustained CPU use by Hyper may cause Tableau Server to become inaccessible. Hyper may be terminated numerous times for sustained high CPU utilization.


  • Tableau Server
    • 2022.1.7 and newer
    • 2021.4.11 and newer
    • 2021.3.16 and newer
    • 2021.2.17 and newer
    • 2021.1.19 and newer
  • Windows
  • Linux


To identify and mitigate this issue, confirm that all three of the following factors are true:

  1. Extracts using SQL queries with CROSS JOIN are used on the server
    • Hyper logs on the server will show CROSS JOIN queries occurring shortly before or during the issue 
  2. Hyper CPU utilization is higher than it was before the upgrade, and may hit 100% of available resources.
  3. Setting native_api.logical.query.rewrite.disableJoin:PostFuse resolves the above behavior in #2 (even if there are other performance impacts as a result of this change).
Note that, after the Join:PostFuse rewrite rule has been disabled, the performance of queries that use CROSS JOIN may be slower than before the upgrade. (This includes view loads connecting to these data sources, as well as extract refreshes.) Further testing would be needed to confirm this impact as the performance will vary depending on the query executed.

To disable the Join:PostFuse rewrite rule, use these commands:
tsm configuration set -k native_api.logical.query.rewrite.disable -v Join:PostFuse --force-keys
tsm pending-changes apply

If needed, the above change can be reverted using these commands:

tsm configuration set -k native_api.logical.query.rewrite.disable -d
tsm pending-changes apply

Note: When Tableau Development has released a fix in a future release of the product, this article will be updated and, after upgrading to that version of the product, the change can be reverted using the above command, where -d sets the value back to its default of the rule being enabled.


This behavior is linked to a Known Issue with ID 1478710 to be resolved in a future release.
Did this article resolve the issue?