<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE article PUBLIC "-//NLM//DTD JATS (Z39.96) Journal Publishing DTD v1.3 20210610//EN" "JATS-journalpublishing1-3-mathml3.dtd">
<article xml:lang="EN" xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink" xmlns:ali="http://www.niso.org/schemas/ali/1.0/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" dtd-version="1.3" article-type="research-article">
<front>
<journal-meta>
<journal-id journal-id-type="publisher-id">Front. Comput. Sci.</journal-id>
<journal-title-group>
<journal-title>Frontiers in Computer Science</journal-title>
<abbrev-journal-title abbrev-type="pubmed">Front. Comput. Sci.</abbrev-journal-title>
</journal-title-group>
<issn pub-type="epub">2624-9898</issn>
<publisher>
<publisher-name>Frontiers Media S.A.</publisher-name>
</publisher>
</journal-meta>
<article-meta>
<article-id pub-id-type="doi">10.3389/fcomp.2025.1649354</article-id>
<article-version article-version-type="Version of Record" vocab="NISO-RP-8-2008"/>
<article-categories>
<subj-group subj-group-type="heading">
<subject>Original Research</subject>
</subj-group>
</article-categories>
<title-group>
<article-title>Left-deep join order selection with higher-order unconstrained binary optimization on quantum computers</article-title>
</title-group>
<contrib-group>
<contrib contrib-type="author" corresp="yes">
<name><surname>Uotila</surname> <given-names>Valter</given-names></name>
<xref ref-type="aff" rid="aff1"/>
<xref ref-type="corresp" rid="c001"><sup>&#x0002A;</sup></xref>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Writing &#x2013; original draft" vocab-term-identifier="https://credit.niso.org/contributor-roles/writing-original-draft/">Writing &#x2013; original draft</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Software" vocab-term-identifier="https://credit.niso.org/contributor-roles/software/">Software</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Writing &#x2013; review &amp; editing" vocab-term-identifier="https://credit.niso.org/contributor-roles/writing-review-editing/">Writing &#x2013; review &#x00026; editing</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Data curation" vocab-term-identifier="https://credit.niso.org/contributor-roles/data-curation/">Data curation</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Conceptualization" vocab-term-identifier="https://credit.niso.org/contributor-roles/conceptualization/">Conceptualization</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Investigation" vocab-term-identifier="https://credit.niso.org/contributor-roles/investigation/">Investigation</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Formal analysis" vocab-term-identifier="https://credit.niso.org/contributor-roles/formal-analysis/">Formal analysis</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Visualization" vocab-term-identifier="https://credit.niso.org/contributor-roles/visualization/">Visualization</role>
<role vocab="credit" vocab-identifier="https://credit.niso.org/" vocab-term="Methodology" vocab-term-identifier="https://credit.niso.org/contributor-roles/methodology/">Methodology</role>
<uri xlink:href="https://loop.frontiersin.org/people/3068292"/>
</contrib>
</contrib-group>
<aff id="aff1"><institution>Department of Computer Science, University of Helsinki</institution>, <city>Helsinki</city>, <country country="fi">Finland</country></aff>
<author-notes>
<corresp id="c001"><label>&#x0002A;</label>Correspondence: Valter Uotila, <email xlink:href="mailto:valter.uotila@helsinki.fi">valter.uotila@helsinki.fi</email></corresp>
</author-notes>
<pub-date publication-format="electronic" date-type="pub" iso-8601-date="2025-10-07">
<day>07</day>
<month>10</month>
<year>2025</year>
</pub-date>
<pub-date publication-format="electronic" date-type="collection">
<year>2025</year>
</pub-date>
<volume>7</volume>
<elocation-id>1649354</elocation-id>
<history>
<date date-type="received">
<day>18</day>
<month>06</month>
<year>2025</year>
</date>
<date date-type="accepted">
<day>12</day>
<month>09</month>
<year>2025</year>
</date>
</history>
<permissions>
<copyright-statement>Copyright &#x000A9; 2025 Uotila.</copyright-statement>
<copyright-year>2025</copyright-year>
<copyright-holder>Uotila</copyright-holder>
<license>
<ali:license_ref start_date="2025-10-07">https://creativecommons.org/licenses/by/4.0/</ali:license_ref>
<license-p>This is an open-access article distributed under the terms of the <ext-link ext-link-type="uri" xlink:href="https://creativecommons.org/licenses/by/4.0/">Creative Commons Attribution License (CC BY)</ext-link>. The use, distribution or reproduction in other forums is permitted, provided the original author(s) and the copyright owner(s) are credited and that the original publication in this journal is cited, in accordance with accepted academic practice. No use, distribution or reproduction is permitted which does not comply with these terms.</license-p>
</license>
</permissions>
<abstract>
<p>Join order optimization is among the most crucial query optimization problems, and its central position is also evident in the new research field where quantum computing is applied to database optimization and data management. In this field, join order optimization is the most studied database problem, typically tackled with a quadratic unconstrained binary optimization model, which is solved using various meta-heuristics, such as quantum and digital annealing, the quantum approximate optimization algorithm, or the variational quantum eigensolver. In this study, we continue developing quantum computing techniques for left-deep join order optimization by presenting three novel quantum optimization algorithms. These algorithms are based on a higher-order unconstrained binary optimization model, which is a generalization of the quadratic model and has not previously been applied to database problems. Theoretically, these optimization problems naturally map to universal quantum computers and quantum annealers. Compared to previous studies, two of our algorithms are the first quantum algorithms to model the join order cost function precisely. We prove theoretical bounds by showing that these two methods encode the same plans as the dynamic programming algorithm with respect to the query graph, which provides the optimal result up to cross products. The third algorithm achieves plans at least as good as those of the greedy algorithm with respect to the query graph. These results establish a meaningful theoretical connection between classical and quantum algorithms for selecting left-deep join orders. To demonstrate the practical usability of our algorithms, we have conducted an extensive experimental evaluation on thousands of clique, cycle, star, tree, and chain query graphs using both quantum and classical solvers.</p></abstract>
<kwd-group>
<kwd>quantum computing</kwd>
<kwd>quantum annealing</kwd>
<kwd>query processing</kwd>
<kwd>query optimization</kwd>
<kwd>relational databases</kwd>
<kwd>join order selection</kwd>
<kwd>higher-order binary optimization</kwd>
</kwd-group>
<funding-group>
<funding-statement>The author(s) declare that financial support was received for the research and/or publication of this article. Open access funded by Helsinki University Library.</funding-statement>
</funding-group>
<counts>
<fig-count count="13"/>
<table-count count="1"/>
<equation-count count="38"/>
<ref-count count="84"/>
<page-count count="24"/>
<word-count count="16651"/>
</counts>
<custom-meta-group>
<custom-meta>
<meta-name>section-at-acceptance</meta-name>
<meta-value>Theoretical Computer Science</meta-value>
</custom-meta>
</custom-meta-group>
</article-meta>
</front>
<body>
<sec sec-type="intro" id="s1">
<label>1</label>
<title>Introduction</title>
<p>Join order optimization is one of the critical stages in query optimization, where the goal is to determine the most efficient sequence in which joins should be performed (<xref ref-type="bibr" rid="B61">Selinger et al., 1979</xref>). Join order optimization plays a central role, as the order of joins determines whether a query finishes in seconds or hours, especially in large databases (<xref ref-type="bibr" rid="B46">Neumann and Radke, 2018</xref>). The problem is a well-researched NP-hard problem (<xref ref-type="bibr" rid="B27">Ibaraki and Kameda, 1984</xref>) with various exhaustive and heuristic solutions (<xref ref-type="bibr" rid="B34">Leis et al., 2015</xref>; <xref ref-type="bibr" rid="B63">Steinbrunn et al., 1997</xref>). The central position of join order optimization in database research is also evident in the new research field where quantum computing is applied to database optimization and data management (<xref ref-type="bibr" rid="B56">Sch&#x000F6;nberger, 2022</xref>; <xref ref-type="bibr" rid="B69">Uotila, 2022</xref>). In this subfield, the join order selection problem is the most studied (<xref ref-type="bibr" rid="B57">Sch&#x000F6;nberger et al., 2023a</xref>; <xref ref-type="bibr" rid="B81">Winker et al., 2023a</xref>; <xref ref-type="bibr" rid="B59">Sch&#x000F6;nberger et al., 2023c</xref>; <xref ref-type="bibr" rid="B43">Nayak et al., 2024</xref>; <xref ref-type="bibr" rid="B19">Franz et al., 2024</xref>; <xref ref-type="bibr" rid="B58">Sch&#x000F6;nberger et al., 2023b</xref>; <xref ref-type="bibr" rid="B55">Saxena et al., 2024</xref>; <xref ref-type="bibr" rid="B35">Liu et al., 2025</xref>; <xref ref-type="bibr" rid="B10">&#x000C7;alikyilmaz et al., 2023</xref>). In contrast, other quantum computing problems related to database and data management include index selection (<xref ref-type="bibr" rid="B25">Gruenwald et al., 2023</xref>; <xref ref-type="bibr" rid="B68">Trummer and Venturelli, 2024</xref>), cardinality and query metric estimations (<xref ref-type="bibr" rid="B70">Uotila, 2024a</xref>, <xref ref-type="bibr" rid="B73">2025b</xref>; <xref ref-type="bibr" rid="B32">Kittelmann et al., 2024</xref>), transaction scheduling (<xref ref-type="bibr" rid="B7">Bittner and Groppe, 2020</xref>; <xref ref-type="bibr" rid="B42">Nayak et al., 2025</xref>), resource allocation (<xref ref-type="bibr" rid="B75">Uotila and Lu, 2023</xref>; <xref ref-type="bibr" rid="B65">Trummer, 2025</xref>), schema matching (<xref ref-type="bibr" rid="B20">Fritsch and Scherzinger, 2023</xref>), relational deep learning (<xref ref-type="bibr" rid="B77">Vogrin et al., 2024</xref>), and multiple query optimization (<xref ref-type="bibr" rid="B66">Trummer and Koch, 2016</xref>).</p>
<p>Despite the interest in optimizing databases with quantum computers, demonstrating a clear quantum advantage in database-related problems remains open. Generally, demonstrating an advantage of quantum over classical algorithms has proved challenging in practice. Some experiments demonstrate specific forms of quantum advantage (<xref ref-type="bibr" rid="B6">Arute et al., 2019</xref>; <xref ref-type="bibr" rid="B26">Harrow and Montanaro, 2017</xref>; <xref ref-type="bibr" rid="B29">Kim et al., 2023</xref>; <xref ref-type="bibr" rid="B30">King et al., 2024</xref>; <xref ref-type="bibr" rid="B37">Madsen et al., 2022</xref>; <xref ref-type="bibr" rid="B83">Zhong et al., 2020</xref>; <xref ref-type="bibr" rid="B84">Zhu et al., 2021</xref>), but none show widely accepted benefits over classical algorithms in real-life applications. On the other hand, some algorithms such as <xref ref-type="bibr" rid="B62">Shor&#x00027;s (1994)</xref> and <xref ref-type="bibr" rid="B24">Grover&#x00027;s (1996)</xref> algorithms show a provable advantage over the best classical algorithms on fault-tolerant quantum computers, which do not yet exist.</p>
<p>Since demonstrating benefits from current quantum computers has proved challenging, <xref ref-type="bibr" rid="B58">Sch&#x000F6;nberger et al. (2023b)</xref> suggested moving from quantum hardware to quantum-inspired hardware, especially in join order optimization. They argued that special-purpose solvers and hardware, such as digital annealers, should be used. While they demonstrated that this direction is promising and feasible, they did not extensively examine the potential benefits of modifying the underlying quantum optimization model, which has been similar to the previous mixed-integer linear programming solution for the join order selection problem (<xref ref-type="bibr" rid="B67">Trummer and Koch, 2017</xref>).</p>
<p>If we seek (database) applications that are likely to benefit from quantum computing, one of our central arguments is that we might want to move from quadratic to higher-order models. Focusing on the quantum computing paradigm that is restricted to quadratic interactions between qubits, previous studies has shown that there are only particular problems where these devices beat classical computers (<xref ref-type="bibr" rid="B13">Denchev et al., 2016</xref>; <xref ref-type="bibr" rid="B30">King et al., 2024</xref>). On the other hand, there is no evidence that this advantage would transfer to practically relevant problems (<xref ref-type="bibr" rid="B80">Willsch et al., 2022</xref>).</p>
<p>In this study, we depart from quadratic models and instead investigate higher-order binary optimization. As a continuation of the idea to revise the underlying assumptions about hardware (relaxing from quantum to quantum-inspired), we suggest applying a special optimization model, a higher-order binary optimization model, which is a relaxation of the previously widely used quadratic model (<xref ref-type="bibr" rid="B57">Sch&#x000F6;nberger et al., 2023a</xref>; <xref ref-type="bibr" rid="B67">Trummer and Koch, 2017</xref>; <xref ref-type="bibr" rid="B58">Sch&#x000F6;nberger et al., 2023b</xref>,<xref ref-type="bibr" rid="B59">c</xref>; <xref ref-type="bibr" rid="B43">Nayak et al., 2024</xref>; <xref ref-type="bibr" rid="B55">Saxena et al., 2024</xref>). We develop three higher-order binary optimization formulations for the join order selection problem in relational databases, with a focus on left-deep join trees. We present two theoretical results that connect the performance of these methods to the classical dynamic programming and greedy algorithms. Finally, we demonstrate the utility of the proposed algorithms by evaluating the methods on quantum annealers and classical solvers. This evaluation also demonstrates differences between quantum annealers and classical solvers at a concrete application-level problem.</p>
<p>The previous quantum computing formulations for the join order selection problem did not benefit from the query graph&#x00027;s structure, which we encode in the optimization problem formulations. By using information from the query graphs and assuming that cross products are computationally expensive, we can reduce the size of the optimization problems. The other critical scalability finding lies in the selection of binary variables. With a clever choice of binary variables, we can compute the cost precisely and reduce the number of variables and their types. The previous studies (<xref ref-type="bibr" rid="B57">Sch&#x000F6;nberger et al., 2023a</xref>,<xref ref-type="bibr" rid="B58">b</xref>) has used four variable types (variables for relations, joins, predicates, and cost approximation). We decrease this number to one variable type, which works in most cases, except for clique graphs, which require two types.</p>
<p>Quantum computing research for database applications has not provided many precise theoretical results regarding the performance of the developed methods. In this study, we prove two bounds for our methods, which connect the quantum algorithms to the classical ones. This is important because it helps in understanding the capabilities of current quantum computation solutions compared to established classical methods.</p>
<p>The key contributions are as follows:</p>
<list list-type="order">
<list-item><p>We introduce three higher-order unconstrained binary optimization formulations for join order optimization, designed for quantum annealers and classical solvers.</p></list-item>
<list-item><p>We prove theoretical bounds that connect these formulations to classical dynamic programming and greedy algorithms.</p></list-item>
<list-item><p>We perform an extensive experimental evaluation, demonstrating both the practicality of our methods and the contrasting capabilities of quantum and classical solvers.</p></list-item>
</list>
<p>The structure of the article is as follows. First, we formally state the join order selection problem, discuss the quadratic and higher-order binary optimization models, and define their connection to quantum computing. Then, we present the main algorithms. We prove the theoretical bounds for the accuracy of the methods. We summarize the results from the experimental evaluation and discuss how our contributions relate to previous studies on solving the join order selection problem using quantum computing. The implementation is available on GitHub (<xref ref-type="bibr" rid="B72">Uotila, 2025a</xref>).</p>
</sec>
<sec id="s2">
<label>2</label>
<title>Problem definition and background</title>
<sec>
<label>2.1</label>
<title>Join order selection problem</title>
<p>We start by defining the join order selection problem. Informally, the problem involves executing a SQL query that joins tables in a fixed relational database. The order of the joins affects the intermediate results and thus the total execution cost of the query. The join order selection problem is known to be NP-hard in the number of relations (<xref ref-type="bibr" rid="B27">Ibaraki and Kameda, 1984</xref>). The hardness motivates the need for heuristics, approximation methods, and potentially quantum optimization approaches. We will focus on the computational complexity in the theoretical analysis.</p>
<p>We assume the SQL queries are given as query graphs of the form <italic>G</italic> &#x0003D; (<italic>V, E</italic>), where <italic>V</italic> is the set of nodes (i.e., tables or relations) and edges define the required joins between the relations. <xref ref-type="fig" rid="F1">Figure 1</xref> illustrates a simple SQL query and its corresponding query graph, where nodes represent relations and edges represent join predicates. We denote relations as <italic>R</italic><sub><italic>i</italic></sub> for a non-negative integer <italic>i</italic>. Then, the set <italic>E</italic> is the set of edges defined by join predicates <italic>p</italic><sub><italic>ij</italic></sub> between relations <italic>R</italic><sub><italic>i</italic></sub> and <italic>R</italic><sub><italic>j</italic></sub>. Every relation <italic>R</italic><sub><italic>i</italic></sub> has a cardinality, denoted by |<italic>R</italic><sub><italic>i</italic></sub>|, and every predicate has a selectivity 0 &#x0003C; <italic>f</italic><sub><italic>ij</italic></sub> &#x02264; 1. The join is denoted by <italic>R</italic><sub><italic>i</italic></sub> &#x022C8;<sub><italic>p</italic><sub><italic>ij</italic></sub></sub><italic>R</italic><sub><italic>j</italic></sub>. This study assumes that the joins are inner joins, but we will discuss the extension to other joins, such as outer joins.</p>
<fig position="float" id="F1">
<label>Figure 1</label>
<caption><p>SQL query and its corresponding query graph. Each node represents a relation, and edges represent join predicates.</p></caption>
<graphic mimetype="image" mime-subtype="tiff" xlink:href="fcomp-07-1649354-g0001.tif">
<alt-text content-type="machine-generated">SQL query for selecting all columns from tables REL0, REL1, REL2, REL3 using inner joins and conditions on columns. Below is a graph with four circles labeled 0, 1, 2, 3, and connecting lines from 0 to 2, 1 to 2 and 2 to 3.</alt-text>
</graphic>
</fig>
<p>A join tree <italic>T</italic> of a query graph <italic>G</italic> is a binary tree in which each relation of <italic>G</italic> appears exactly once as a leaf node. Each internal node represents the join of its two children. For example, a non-leaf node labeled <italic>R</italic><sub><italic>k</italic><sub>1</sub></sub> &#x022C8; &#x02026; &#x022C8; <italic>R</italic><sub><italic>k</italic><sub><italic>n</italic></sub></sub> has two child subtrees, each of which contains a subset of the relations <italic>R</italic><sub><italic>k</italic><sub>1</sub></sub>, &#x02026;, <italic>R</italic><sub><italic>k</italic><sub><italic>n</italic></sub></sub>. Following the definition in the study by <xref ref-type="bibr" rid="B46">Neumann and Radke (2018)</xref>, we define that a join tree <italic>T</italic> adheres to a query graph <italic>G</italic> if for every subtree <inline-formula><mml:math id="M1"><mml:msup><mml:mrow><mml:mi>T</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup><mml:mo>=</mml:mo><mml:msub><mml:mrow><mml:mi>T</mml:mi></mml:mrow><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>&#x022C8;</mml:mo><mml:msub><mml:mrow><mml:mi>T</mml:mi></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub></mml:math></inline-formula> of <italic>T</italic>, there exists relations <italic>R</italic><sub>1</sub> and <italic>R</italic><sub>2</sub> such that <italic>R</italic><sub>1</sub> &#x02208; <italic>T</italic><sub>1</sub> and <italic>R</italic><sub>2</sub> &#x02208; <italic>T</italic><sub>2</sub> and (<italic>R</italic><sub>1</sub>, <italic>R</italic><sub>2</sub>) &#x02208; <italic>E</italic>. The join order selection problem is finding a join tree <italic>T</italic> that adheres to the query graph <italic>G</italic> and minimizes a given cost function. In this article, we refer to the requirement that a join tree adheres to the query graph as the validity constraint and the requirement of minimizing execution cost as the cost constraint. Next, we define the standard cost function for join trees.</p>
<p>Standard cost functions are based on estimating cardinalities of intermediate results in the join order selection process (<xref ref-type="bibr" rid="B34">Leis et al., 2015</xref>; <xref ref-type="bibr" rid="B45">Neumann and Gubichev, 2014</xref>; <xref ref-type="bibr" rid="B12">Cluet and Moerkotte, 1995</xref>). Thus, we first define how to compute the cardinality of a given join tree <italic>T</italic>. For a join tree <italic>T</italic>, its cardinality is defined recursively.</p>
<disp-formula id="EQ1"><mml:math id="M2"><mml:mtable class="eqnarray" columnalign="left"><mml:mtr><mml:mtd><mml:mrow><mml:mo>|</mml:mo><mml:mi>T</mml:mi><mml:mo>|</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:mtable class="eqnarray" columnalign="left"><mml:mtr><mml:mtd><mml:mtext>&#x000A0;</mml:mtext><mml:mrow><mml:mo>|</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>|</mml:mo></mml:mrow></mml:mtd><mml:mtd><mml:mtext>&#x02003;</mml:mtext><mml:mtext class="textrm" mathvariant="normal">if&#x000A0;</mml:mtext><mml:mi>T</mml:mi><mml:mo>=</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mtext class="textrm" mathvariant="normal">&#x000A0;is a leaf node,</mml:mtext></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mtext>&#x000A0;</mml:mtext><mml:mrow><mml:mo stretchy="true">(</mml:mo><mml:mrow><mml:mstyle displaystyle="true"><mml:msub><mml:mrow><mml:mo>&#x0220F;</mml:mo></mml:mrow><mml:mrow><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>&#x02208;</mml:mo><mml:msub><mml:mrow><mml:mi>T</mml:mi></mml:mrow><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mi>j</mml:mi></mml:mrow></mml:msub><mml:mo>&#x02208;</mml:mo><mml:msub><mml:mrow><mml:mi>T</mml:mi></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub></mml:mrow></mml:msub></mml:mstyle><mml:msub><mml:mrow><mml:mi>f</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mi>j</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mo stretchy="true">)</mml:mo></mml:mrow><mml:mo>|</mml:mo><mml:msub><mml:mrow><mml:mi>T</mml:mi></mml:mrow><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>|</mml:mo><mml:mo>|</mml:mo><mml:msub><mml:mrow><mml:mi>T</mml:mi></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo>|</mml:mo></mml:mtd><mml:mtd><mml:mtext>&#x02003;</mml:mtext><mml:mtext class="textrm" mathvariant="normal">if&#x000A0;</mml:mtext><mml:mi>T</mml:mi><mml:mo>=</mml:mo><mml:msub><mml:mrow><mml:mi>T</mml:mi></mml:mrow><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>&#x022C8;</mml:mo><mml:msub><mml:mrow><mml:mi>T</mml:mi></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo>.</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:mrow></mml:mrow></mml:mtd></mml:mtr></mml:mtable></mml:math><label>(1)</label></disp-formula>
<p>Based on the cardinalities, we define the cost function recursively as</p>
<disp-formula id="EQ2"><mml:math id="M3"><mml:mtable class="eqnarray" columnalign="left"><mml:mtr><mml:mtd><mml:mi>C</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>T</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:mtable class="eqnarray" columnalign="left"><mml:mtr><mml:mtd><mml:mtext>&#x000A0;</mml:mtext><mml:mn>0</mml:mn></mml:mtd><mml:mtd><mml:mtext>&#x02003;</mml:mtext><mml:mtext class="textrm" mathvariant="normal">if&#x000A0;</mml:mtext><mml:mi>T</mml:mi><mml:mo>=</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mtext class="textrm" mathvariant="normal">&#x000A0;is a leaf node,</mml:mtext></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mtext>&#x000A0;</mml:mtext><mml:mo>|</mml:mo><mml:mi>T</mml:mi><mml:mo>|</mml:mo><mml:mo>&#x0002B;</mml:mo><mml:mi>C</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>T</mml:mi></mml:mrow><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x0002B;</mml:mo><mml:mi>C</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>T</mml:mi></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mtd><mml:mtd><mml:mtext>&#x02003;</mml:mtext><mml:mtext class="textrm" mathvariant="normal">if&#x000A0;</mml:mtext><mml:mi>T</mml:mi><mml:mo>=</mml:mo><mml:msub><mml:mrow><mml:mi>T</mml:mi></mml:mrow><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>&#x022C8;</mml:mo><mml:msub><mml:mrow><mml:mi>T</mml:mi></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo>.</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:mrow></mml:mrow></mml:mtd></mml:mtr></mml:mtable></mml:math><label>(2)</label></disp-formula>
<p>This is the standard cost function (<xref ref-type="bibr" rid="B12">Cluet and Moerkotte, 1995</xref>), which has also been used in earlier quantum computing formulations (<xref ref-type="bibr" rid="B57">Sch&#x000F6;nberger et al., 2023a</xref>,<xref ref-type="bibr" rid="B58">b</xref>,<xref ref-type="bibr" rid="B59">c</xref>) and in the corresponding mixed-integer linear programming formulation (<xref ref-type="bibr" rid="B67">Trummer and Koch, 2017</xref>). More sophisticated cost models exist, whose integration into quantum optimization formulations will be part of future research.</p>
<p>In practice, two additional restrictions are common in join order optimization. First, query optimizers may avoid cross-product joins (also known as Cartesian products) because they produce large intermediate results. Unless explicitly required by the query graph, cross products are excluded from consideration. In our formulation, this differs from many previous quantum formulations, making our approach query-graph-aware. Second, optimizers often restrict the search space to left-deep join trees, where each join combines an intermediate result with a leaf relation. Left-deep trees dramatically reduce the search space compared to bushy join trees, where both join inputs can be intermediate results. Although bushy trees often yield lower costs, the blowup of the search space in possible plans makes them impractical for large queries. In this study, we follow these conventions and focus on left-deep join trees without cross products. It will be part of future research to include cross products, bushy trees, and more sophisticated cost functions.</p>
</sec>
<sec>
<label>2.2</label>
<title>Dynamic programming and greedy algorithms for join order selection</title>
<p>Our implementations of dynamic programming and greedy algorithms follow the study by <xref ref-type="bibr" rid="B45">Neumann and Gubichev (2014)</xref>. They are well known and commonly used algorithms for join order selection (<xref ref-type="bibr" rid="B61">Selinger et al., 1979</xref>; <xref ref-type="bibr" rid="B46">Neumann and Radke, 2018</xref>; <xref ref-type="bibr" rid="B39">Moerkotte and Neumann, 2006</xref>, <xref ref-type="bibr" rid="B40">2008</xref>). We present them in detail to build a clearer connection between them and the higher-order binary optimization formulation we develop in this work. Dynamic programming provides a general framework for systematically exploring possible join orders. In our study, we have fixed the cost function (<xref ref-type="disp-formula" rid="EQ2">Equation 2</xref>) and employed the dynamic programming algorithm with and without cross products. The algorithm without cross products is presented in <xref ref-type="statement" rid="algo1">Algorithm 1</xref>. It relies on functions that create left-deep trees for trees <italic>T</italic><sub>1</sub> and <italic>T</italic><sub>2</sub> and return costs for join trees based on the cost function in <xref ref-type="disp-formula" rid="EQ2">Equation 2</xref>.</p>
<statement content-type="algorithm" id="algo1">
<label>Algorithm 1</label>
<title>Dynamic programming for left-deep join order selection with cross products.</title>
<p><monospace><bold>Input:</bold> &#x000A0; relations <italic>R</italic> &#x0003D; {<italic>r</italic><sub>1</sub>, <italic>r</italic><sub>2</sub>, &#x02026;, <italic>r</italic><sub><italic>n</italic></sub>}, selectivities <italic>S</italic></monospace></p>
<p><monospace><bold>Output:</bold> &#x000A0; optimal left-deep join tree in dp_table[<italic>R</italic>]</monospace></p>
<p>&#x000A0;<monospace>1: initialize dp_table</monospace></p>
<p>&#x000A0;<monospace>2: <bold>for</bold> <italic>r</italic> &#x02208; <italic>R</italic> <bold>do</bold></monospace></p>
<p>&#x000A0;<monospace>3: &#x000A0;&#x000A0;&#x000A0;&#x000A0;dp_table[{<italic>r</italic>}] &#x02190; <italic>r</italic> &#x022B3; Base case: single relation</monospace></p>
<p>&#x000A0;<monospace>4: <bold>end for</bold></monospace></p>
<p>&#x000A0;<monospace>5: <bold>for</bold> <italic>s</italic> &#x0003D; 2 <bold>to</bold> |<italic>R</italic>| <bold>do</bold> &#x022B3; Size of subsets from 2 to <italic>n</italic></monospace></p>
<p>&#x000A0;<monospace>6: &#x000A0;&#x000A0;&#x000A0;&#x000A0;<bold>for</bold> subset &#x02286; <italic>R</italic> such that |subset| &#x0003D; <italic>s</italic> &#x02212; 1 <bold>do</bold></monospace></p>
<p>&#x000A0;<monospace>7: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<bold>if</bold> subset &#x02208; dp_table <bold>then</bold></monospace></p>
<p>&#x000A0;<monospace>8: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<bold>for</bold> <italic>r</italic> &#x02208; <italic>R</italic>\subset <bold>do</bold></monospace></p>
<p><monospace>&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x022B3; Relations not in subset</monospace></p>
<p>&#x000A0;<monospace>9: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<italic>T</italic><sub>1</sub> &#x02190; dp_table[subset]</monospace></p>
<p><monospace>10: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<italic>T</italic><sub>2</sub> &#x02190; dp_table[{<italic>r</italic>}]</monospace></p>
<p><monospace>&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x022B3; <italic>T</italic><sub>2</sub> is leaf node making this left-deep</monospace></p>
<p><monospace>11: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;T, T_cost &#x02190; create_join_tree(<italic>T</italic><sub>1</sub>, <italic>T</italic><sub>2</sub>, <italic>R, S</italic>)</monospace></p>
<p><monospace>12: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;join_key &#x02190; subset&#x0222A;{<italic>r</italic>}</monospace></p>
<p><monospace>13: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<bold>if</bold> join_key&#x02209;dp_table <bold>then</bold></monospace></p>
<p><monospace>14: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;dp_table[join_key] &#x02190; <italic>T</italic></monospace></p>
<p><monospace>&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x022B3; Update if key not in table</monospace></p>
<p><monospace>15: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<bold>else</bold></monospace></p>
<p><monospace>16: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;prev_cost &#x02190; <bold>cost</bold>(dp_table[join_key], <italic>R, S</italic>)</monospace></p>
<p><monospace>17: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<bold>if</bold> T_cost &#x0003C; prev_cost <bold>then</bold></monospace></p>
<p><monospace>18: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;dp_table[join_key] &#x02190; <italic>T</italic></monospace></p>
<p><monospace>&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x022B3; Update if lower cost</monospace></p>
<p><monospace>19: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<bold>end if</bold></monospace></p>
<p><monospace>20: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<bold>end if</bold></monospace></p>
<p><monospace>21: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<bold>end for</bold></monospace></p>
<p><monospace>22: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<bold>end if</bold></monospace></p>
<p><monospace>23: &#x000A0;&#x000A0;&#x000A0;&#x000A0;<bold>end for</bold></monospace></p>
<p><monospace>24: <bold>end for</bold></monospace></p>
</statement>
<p>The algorithm that computes the dynamic programming result without cross products is similar, except that for a query graph <italic>G</italic>, we change line 6: <bold>for</bold> connected subgraph &#x02282; <italic>G</italic> such that |subgraph| &#x0003D; <italic>s</italic> &#x02212; 1 <bold>do</bold>. Then, the algorithm proceeds with the connected subgraphs of size <italic>s</italic> &#x02212; 1, instead of all subsets of size <italic>s</italic> &#x02212; 1.</p>
<p>The greedy algorithm is another standard algorithm for optimizing join order selection, as represented in <xref ref-type="statement" rid="algo2">Algorithm 2</xref>. Similar to the dynamic programming algorithm, we can consider only solutions without cross products so that we iterate only over relations connected to one of the relations already joined. In other words, at each step, we compute a value called adjacent_relations, which contains those relations <italic>R</italic><sub><italic>i</italic></sub> so that if edge (<italic>R</italic><sub><italic>i</italic></sub>, <italic>R</italic><sub><italic>j</italic></sub>) &#x02208; <italic>G</italic> in the query graph <italic>G</italic>, then <italic>R</italic><sub><italic>i</italic></sub> &#x02209; joined_relations but <italic>R</italic><sub><italic>j</italic></sub> &#x02208; joined_relations.</p>
<statement content-type="algorithm" id="algo2">
<label>Algorithm 2</label>
<title>Greedy algorithm for left-deep join order selection with cross products.</title>
<p><monospace><bold>Input:</bold> relations <italic>R</italic> &#x0003D; {<italic>r</italic><sub>1</sub>, &#x02026;, <italic>r</italic><sub><italic>n</italic></sub>}, selectivities <italic>S</italic></monospace></p>
<p><monospace><bold>Output:</bold> Greedy join order tree</monospace></p>
<p>&#x000A0;<monospace>1: &#x000A0;&#x000A0;&#x000A0;&#x000A0;join_result &#x02190; [<italic>r</italic><sub><italic>i</italic></sub>, <italic>r</italic><sub><italic>j</italic></sub>] so that <italic>f</italic><sub><italic>i, j</italic></sub>|<italic>r</italic><sub><italic>i</italic></sub>||<italic>r</italic><sub><italic>j</italic></sub>| is the smallest</monospace></p>
<p>&#x000A0;<monospace>2: &#x000A0;&#x000A0;&#x000A0;&#x000A0;<bold>for</bold> 1 to |<italic>R</italic>|&#x02212;2 <bold>do</bold></monospace></p>
<p>&#x000A0;<monospace>3: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;min_cost &#x02190; &#x0221E;</monospace></p>
<p>&#x000A0;<monospace>4: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;min_table &#x02190; None</monospace></p>
<p>&#x000A0;<monospace>5: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<bold>for</bold> table &#x02208; <italic>R</italic> \join_result <bold>do</bold></monospace></p>
<p><monospace>&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x022B3; Iterate over tables which are not joined</monospace></p>
<p>&#x000A0;<monospace>6: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;current_join_tree &#x02190; [table, join_result]</monospace></p>
<p>&#x000A0;<monospace>7: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;current_cost &#x02190; <bold>cost</bold>(current_join_tree, <italic>R, S</italic>)</monospace></p>
<p>&#x000A0;<monospace>8: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<bold>if</bold> current_cost &#x0003C; min_cost <bold>then</bold></monospace></p>
<p><monospace>&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x022B3; Choose table with smallest cost</monospace></p>
<p>&#x000A0;<monospace>9: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;min_cost &#x02190; current_cost</monospace></p>
<p><monospace>10:&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;min_table &#x02190; table</monospace></p>
<p><monospace>11: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<bold>end if</bold></monospace></p>
<p><monospace>12: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<bold>end for</bold></monospace></p>
<p><monospace>13: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;join_result &#x02190; [min_table, join_result]</monospace></p>
<p><monospace>14: &#x000A0;&#x000A0;&#x000A0;&#x000A0;<bold>end for</bold></monospace></p>
</statement>
</sec>
<sec>
<label>2.3</label>
<title>Unconstrained binary optimization</title>
<p>Optimization is one of the key fields where quantum computing is assumed to provide computational value (<xref ref-type="bibr" rid="B1">Abbas and et al., 2024</xref>). This part provides a brief and high-level overview of how optimization algorithms are developed in quantum computing. We guide the reader to the study by <xref ref-type="bibr" rid="B47">Nielsen and Chuang (2010)</xref> and <xref ref-type="bibr" rid="B82">Winker et al. (2023b)</xref> for more detailed information about quantum computing. Additionally, the study by <xref ref-type="bibr" rid="B57">Sch&#x000F6;nberger et al. (2023a)</xref> provides an excellent introduction to quantum annealing and quadratic unconstrained binary optimization models for a database specialist.</p>
<p>Our study relies on higher-order unconstrained binary optimization (HUBO) (<xref ref-type="bibr" rid="B8">Boros and Hammer, 2002</xref>) problems, which are a generalization of quadratic unconstrained binary optimization (QUBO) problems. To the best of our knowledge, there is limited research on formulating domain-specific problems using HUBOs, which we will cover in more detail in the Discussion section. One reason for this is that HUBO problems are complex to solve not only theoretically but also practically (<xref ref-type="bibr" rid="B8">Boros and Hammer, 2002</xref>). Due to this computational complexity, they provide a potential area for exploring the practical benefits of quantum computing over classical approaches. Despite being challenging, they have a straightforward quantum computational formulation in theory (<xref ref-type="bibr" rid="B76">Verchere et al., 2023</xref>).</p>
<p>Next, we formally define HUBO problems (<xref ref-type="bibr" rid="B8">Boros and Hammer, 2002</xref>) and demonstrate their connection to QUBO problems. Let [<italic>n</italic>] &#x0003D; {1, &#x02026;, <italic>n</italic>} be an indexing set. Let <italic>x</italic> &#x02208; {0, 1}<sup><italic>n</italic></sup> be a binary variable vector of type <italic>x</italic> &#x0003D; (<italic>x</italic><sub>1</sub>, &#x02026;, <italic>x</italic><sub><italic>n</italic></sub>) so that <italic>x</italic><sub><italic>i</italic></sub> &#x02208; {0, 1} represents values false and true for each <italic>i</italic> &#x02208; [<italic>n</italic>]. The HUBO problem is the following minimization problem of a binary polynomial:</p>
<disp-formula id="EQ3"><mml:math id="M4"><mml:mtable class="eqnarray" columnalign="left"><mml:mtr><mml:mtd><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo class="qopname">arg&#x000A0;min</mml:mo></mml:mrow><mml:mrow><mml:mi>x</mml:mi><mml:mo>&#x02208;</mml:mo><mml:msup><mml:mrow><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:mn>0</mml:mn><mml:mo>,</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mo>}</mml:mo></mml:mrow></mml:mrow><mml:mrow><mml:mi>n</mml:mi></mml:mrow></mml:msup></mml:mrow></mml:munder></mml:mstyle><mml:mtext>&#x000A0;</mml:mtext><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>S</mml:mi><mml:mo>&#x02282;</mml:mo><mml:mrow><mml:mo stretchy="false">[</mml:mo><mml:mrow><mml:mi>n</mml:mi></mml:mrow><mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:mrow></mml:munder></mml:mstyle><mml:msub><mml:mrow><mml:mi>&#x003B1;</mml:mi></mml:mrow><mml:mrow><mml:mi>S</mml:mi></mml:mrow></mml:msub><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x0220F;</mml:mo></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>&#x02208;</mml:mo><mml:mi>S</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:msub><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math><label>(3)</label></disp-formula>
<p>where &#x003B1;<sub><italic>S</italic></sub> &#x02208; &#x0211D;. For each non-empty subset <italic>S</italic>, we have the corresponding higher-order term &#x003B1;<sub><italic>S</italic></sub> &#x0220F; <sub><italic>i</italic> &#x02208; <italic>S</italic></sub> <italic>x</italic><sub><italic>i</italic></sub>. In practice, we might have &#x003B1;<sub><italic>S</italic></sub> &#x0003D; 0 for many terms. In the worst case, we have 2<sup><italic>n</italic></sup> &#x02212; 1 terms. Alternatively, we can write the same polynomial as</p>
<disp-formula id="EQ4"><mml:math id="M5"><mml:mtable class="eqnarray" columnalign="left"><mml:mtr><mml:mtd><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>S</mml:mi><mml:mo>&#x02282;</mml:mo><mml:mrow><mml:mo stretchy="false">[</mml:mo><mml:mrow><mml:mi>n</mml:mi></mml:mrow><mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:mrow></mml:munder></mml:mstyle><mml:msub><mml:mrow><mml:mi>&#x003B1;</mml:mi></mml:mrow><mml:mrow><mml:mi>S</mml:mi></mml:mrow></mml:msub><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x0220F;</mml:mo></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>&#x02208;</mml:mo><mml:mi>S</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:msub><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>&#x02208;</mml:mo><mml:mrow><mml:mo stretchy="false">[</mml:mo><mml:mrow><mml:mi>n</mml:mi></mml:mrow><mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:mrow></mml:munder></mml:mstyle><mml:msub><mml:mrow><mml:mi>&#x003B1;</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:msub><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>&#x0002B;</mml:mo><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>&#x0003C;</mml:mo><mml:mi>j</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:msub><mml:mrow><mml:mi>&#x003B1;</mml:mi></mml:mrow><mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow></mml:msub><mml:msub><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:msub><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>j</mml:mi></mml:mrow></mml:msub><mml:mo>&#x0002B;</mml:mo><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>&#x0003C;</mml:mo><mml:mi>j</mml:mi><mml:mo>&#x0003C;</mml:mo><mml:mi>k</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:msub><mml:mrow><mml:mi>&#x003B1;</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi><mml:mo>,</mml:mo><mml:mi>k</mml:mi></mml:mrow></mml:msub><mml:msub><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:msub><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>j</mml:mi></mml:mrow></mml:msub><mml:msub><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>k</mml:mi></mml:mrow></mml:msub><mml:mo>&#x0002B;</mml:mo><mml:mo>&#x02026;</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math><label>(4)</label></disp-formula>
<p>Quadratic unconstrained binary optimization (QUBO) problems are a restricted case of HUBO problems, where we consider only subsets of limited size, |<italic>S</italic>| &#x02264; 2. Concretely, a QUBO problem is the minimization problem of the polynomial.</p>
<disp-formula id="EQ5"><mml:math id="M6"><mml:mtable class="eqnarray" columnalign="left"><mml:mtr><mml:mtd><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>&#x02208;</mml:mo><mml:mrow><mml:mo stretchy="false">[</mml:mo><mml:mrow><mml:mi>n</mml:mi></mml:mrow><mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:mrow></mml:munder></mml:mstyle><mml:msub><mml:mrow><mml:mi>&#x003B1;</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:msub><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>&#x0002B;</mml:mo><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>&#x0003C;</mml:mo><mml:mi>j</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:msub><mml:mrow><mml:mi>&#x003B1;</mml:mi></mml:mrow><mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow></mml:msub><mml:msub><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:msub><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>j</mml:mi></mml:mrow></mml:msub><mml:mo>.</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math><label>(5)</label></disp-formula>
<p>Both QUBO and HUBO problems are NP-hard (<xref ref-type="bibr" rid="B36">Lucas, 2014</xref>; <xref ref-type="bibr" rid="B8">Boros and Hammer, 2002</xref>). As discussed, QUBO formalism has been the standard method for tackling database optimization problems, and many other wellknown optimization problems (e.g., knapsack, maxcut, and traveling salesman) have a QUBO formulation (<xref ref-type="bibr" rid="B36">Lucas, 2014</xref>).</p>
</sec>
<sec>
<label>2.4</label>
<title>Optimization on quantum hardware</title>
<p>Next, we provide a brief introduction to the basics of quantum computing for optimization problems and discuss techniques for solving HUBOs and QUBOs on quantum hardware. Quantum computing can be divided into multiple paradigms, both in terms of hardware and software. This division is exceptionally versatile, as there is no single &#x0201C;winning&#x0201D; method for building quantum computers yet. Quantum computers are designed to be built on superconducting circuits (IBM, Google, IQM) (<xref ref-type="bibr" rid="B79">Wendin, 2017</xref>), trapped ions (Quantinuum, IonQ) (<xref ref-type="bibr" rid="B49">Paul, 1990</xref>), neutral atoms (Quera, Pasqal) (<xref ref-type="bibr" rid="B23">Grimm et al., 2000</xref>), photons (Xanadu) (<xref ref-type="bibr" rid="B33">Knill et al., 2001</xref>), diamonds (Quantum Brilliance) (<xref ref-type="bibr" rid="B44">Neumann et al., 2008</xref>), and many other quantum mechanical phenomena (<xref ref-type="bibr" rid="B22">Gill et al., 2022</xref>). A special type of quantum hardware is a quantum annealer (D-Wave) (<xref ref-type="bibr" rid="B4">Apolloni et al., 1989</xref>; <xref ref-type="bibr" rid="B28">Kadowaki and Nishimori, 1998</xref>), which does not implement universal quantum computation but offers specific optimization capabilities for QUBO problems.</p>
<p>In addition to the hardware, a partially hardware-dependent software stack is designed to translate and compile high-level quantum algorithms into a format that specific quantum hardware supports. QUBOs are a widely accepted high-level abstraction that can be solved on most quantum hardware. The other common high-level abstraction is quantum circuits. Quantum algorithm design can still be divided into paradigms: adiabatic and circuit-based quantum computing, which are universal quantum computing paradigms (<xref ref-type="bibr" rid="B2">Aharonov et al., 2004</xref>). Unlike traditional introductions to quantum computing, we focus on the fundamentals of adiabatic quantum computing. This choice is motivated by the fact that our experimental evaluation was conducted on a quantum annealer, a type of adiabatic quantum computer.</p>
<p>Quantum computing can be implemented using the adiabatic evolution of a quantum mechanical system (<xref ref-type="bibr" rid="B18">Farhi et al., 2000</xref>; <xref ref-type="bibr" rid="B38">Mc Keever and Lubasch, 2024</xref>). This study uses quantum annealing, which is a part of the adiabatic quantum computing paradigm (<xref ref-type="bibr" rid="B3">Albash and Lidar, 2018</xref>). The evolution of a quantum mechanical system is governed by the Schr&#x000F6;dinger equation (<xref ref-type="bibr" rid="B47">Nielsen and Chuang, 2010</xref>). This evolution models a system with a Hermitian operator known as a Hamiltonian. In this study, we are not interested in arbitrary Hamiltonians but in those with a form that maps to QUBO and HUBO optimization problems. For QUBOs, the corresponding problem Hamiltonian, also called an Ising Hamiltonian, is</p>
<disp-formula id="EQ6"><mml:math id="M7"><mml:mtable class="eqnarray" columnalign="left"><mml:mtr><mml:mtd><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:msub><mml:mrow><mml:mi>h</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:msubsup><mml:mrow><mml:mi>&#x003C3;</mml:mi></mml:mrow><mml:mrow><mml:mi>z</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msubsup><mml:mo>&#x0002B;</mml:mo><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>j</mml:mi><mml:mo>&#x0003C;</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:msub><mml:mrow><mml:mi>J</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow></mml:msub><mml:msubsup><mml:mrow><mml:mi>&#x003C3;</mml:mi></mml:mrow><mml:mrow><mml:mi>z</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msubsup><mml:msubsup><mml:mrow><mml:mi>&#x003C3;</mml:mi></mml:mrow><mml:mrow><mml:mi>z</mml:mi></mml:mrow><mml:mrow><mml:mi>j</mml:mi></mml:mrow></mml:msubsup><mml:mo>,</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math><label>(6)</label></disp-formula>
<p>where <inline-formula><mml:math id="M8"><mml:msubsup><mml:mrow><mml:mi>&#x003C3;</mml:mi></mml:mrow><mml:mrow><mml:mi>z</mml:mi></mml:mrow><mml:mrow><mml:mi>j</mml:mi></mml:mrow></mml:msubsup></mml:math></inline-formula> are Pauli-Z operators for each <italic>j</italic>. The correspondence between the formulations in <xref ref-type="disp-formula" rid="EQ5">Equations 5</xref>, <xref ref-type="disp-formula" rid="EQ6">6</xref> is clear: the coefficients <italic>h</italic><sub><italic>i</italic></sub> and <italic>J</italic><sub><italic>i, j</italic></sub> represent the linear and quadratic terms, respectively. Operator <inline-formula><mml:math id="M9"><mml:msubsup><mml:mrow><mml:mi>&#x003C3;</mml:mi></mml:mrow><mml:mrow><mml:mi>z</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msubsup></mml:math></inline-formula> corresponds to the variable <italic>x</italic><sub><italic>i</italic></sub> for each <italic>i</italic> &#x02208; [<italic>n</italic>]. For HUBOs, the problem Hamiltonian is</p>
<disp-formula id="E7"><mml:math id="M10"><mml:mrow><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>S</mml:mi><mml:mo>&#x02282;</mml:mo><mml:mrow><mml:mo stretchy="false">[</mml:mo><mml:mrow><mml:mi>n</mml:mi></mml:mrow><mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:mrow></mml:munder></mml:mstyle><mml:msub><mml:mrow><mml:mi>&#x003B2;</mml:mi></mml:mrow><mml:mrow><mml:mi>S</mml:mi></mml:mrow></mml:msub><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x0220F;</mml:mo></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>&#x02208;</mml:mo><mml:mi>S</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:msubsup><mml:mrow><mml:mi>&#x003C3;</mml:mi></mml:mrow><mml:mrow><mml:mi>z</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msubsup><mml:mo>,</mml:mo></mml:mrow></mml:math></disp-formula>
<p>where the correspondence to <xref ref-type="disp-formula" rid="EQ4">Equation 4</xref> is similar. As QUBO and HUBO problems are minimization problems, the goal is to find the minimum eigenvalue and eigenstate of the problem Hamiltonian. In other words, we aim to find a quantum state, called a ground state, where Hamiltonian&#x00027;s energy is minimized. As a result, we obtain a solution to the corresponding combinatorial optimization problem (<xref ref-type="bibr" rid="B18">Farhi et al., 2000</xref>).</p>
<p>Next, we describe how adiabatic quantum computing can find the lowest eigenstate and solve the optimization problem. For simplicity, let us focus on solving QUBOs on a quantum annealer. General adiabatic quantum computing is similar (<xref ref-type="bibr" rid="B3">Albash and Lidar, 2018</xref>). We define the following Hamiltonian (<xref ref-type="bibr" rid="B16">D-Wave Quantum Inc., 2025</xref>):</p>
<disp-formula id="EQ8"><mml:math id="M11"><mml:mtable class="eqnarray" columnalign="left"><mml:mtr><mml:mtd><mml:mi>H</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>s</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mstyle displaystyle="true"><mml:munder accentunder="false"><mml:mrow><mml:mo>-</mml:mo><mml:mfrac><mml:mrow><mml:mi>A</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>s</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:mfrac><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:msubsup><mml:mrow><mml:mi>&#x003C3;</mml:mi></mml:mrow><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msubsup></mml:mrow><mml:mo>&#x0FE38;</mml:mo></mml:munder></mml:mstyle></mml:mrow><mml:mrow><mml:mtext class="textrm" mathvariant="normal">initial&#x000A0;Hamiltonian</mml:mtext></mml:mrow></mml:munder></mml:mstyle><mml:mo>&#x0002B;</mml:mo><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mstyle displaystyle="true"><mml:munder accentunder="false"><mml:mrow><mml:mfrac><mml:mrow><mml:mi>B</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>s</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:mfrac><mml:mrow><mml:mo stretchy="true">(</mml:mo><mml:mrow><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:msub><mml:mrow><mml:mi>h</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:msubsup><mml:mrow><mml:mi>&#x003C3;</mml:mi></mml:mrow><mml:mrow><mml:mi>z</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msubsup><mml:mo>&#x0002B;</mml:mo><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>j</mml:mi><mml:mo>&#x0003C;</mml:mo><mml:mi>i</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:msub><mml:mrow><mml:mi>J</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow></mml:msub><mml:msubsup><mml:mrow><mml:mi>&#x003C3;</mml:mi></mml:mrow><mml:mrow><mml:mi>z</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msubsup><mml:msubsup><mml:mrow><mml:mi>&#x003C3;</mml:mi></mml:mrow><mml:mrow><mml:mi>z</mml:mi></mml:mrow><mml:mrow><mml:mi>j</mml:mi></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="true">)</mml:mo></mml:mrow></mml:mrow><mml:mo>&#x0FE38;</mml:mo></mml:munder></mml:mstyle></mml:mrow><mml:mrow><mml:mtext class="textrm" mathvariant="normal">problem&#x000A0;Hamiltonian</mml:mtext></mml:mrow></mml:munder></mml:mstyle><mml:mo>,</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math><label>(7)</label></disp-formula>
<p>where <italic>A</italic>(<italic>s</italic>) is the so-called tunneling energy function and <italic>B</italic>(<italic>s</italic>) is the problem Hamiltonian energy function at <italic>s</italic>. During the annealing process, the value <italic>s</italic> runs from 0 to 1, causing <italic>A</italic>(<italic>s</italic>) &#x02192; 0 and <italic>B</italic>(<italic>s</italic>) &#x02192; 1. We begin with a simple initial Hamiltonian, whose ground state is easily prepared, and gradually evolve it to the problem Hamiltonian. By the adiabatic theorem (<xref ref-type="bibr" rid="B3">Albash and Lidar, 2018</xref>), if the process is slow enough, the system remains in its ground state and ends up solving the optimization problem. However, quantum annealers are limited to solving QUBOs, meaning we cannot encode higher-order terms in the problem Hamiltonian. In contrast, universal adiabatic and gate-based quantum computers do not have this restriction in theory.</p>
<p>Using classical computers, we can solve QUBOs using simulated annealing (<xref ref-type="bibr" rid="B31">Kirkpatrick et al., 1983</xref>), digital annealing (<xref ref-type="bibr" rid="B5">Aramon et al., 2019</xref>), and classical solvers such as Gurobi and CPLEX. Unfortunately, classical solvers, such as quantum annealers, cannot natively solve higher-order binary optimization models; instead, we must rely on rewriting methods that reduce HUBOs to QUBOs. We introduce a reduction method to rewrite higher-order problems into quadratic ones. The key idea is to replace higher-order terms with slack variables. In this study, we primarily rely on the D-Wave Ocean framework&#x00027;s ability to automatically translate HUBO problems into QUBO problems. The HUBO to QUBO reduction based on minimum selection (<xref ref-type="bibr" rid="B15">D-Wave Quantum Inc, 2024</xref>) follows the scheme:</p>
<disp-formula id="E9"><mml:math id="M12"><mml:mtable columnalign="left"><mml:mtr><mml:mtd><mml:mi>x</mml:mi><mml:mi>y</mml:mi><mml:mi>z</mml:mi><mml:mo>=</mml:mo><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo class="qopname">max</mml:mo></mml:mrow><mml:mrow><mml:mi>w</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:mi>w</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>x</mml:mi><mml:mo>&#x0002B;</mml:mo><mml:mi>y</mml:mi><mml:mo>&#x0002B;</mml:mo><mml:mi>z</mml:mi><mml:mo>-</mml:mo><mml:mn>2</mml:mn></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>,</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula>
<p>where <italic>x</italic>, <italic>y</italic>, <italic>z</italic>, and <italic>w</italic> are binary variables. This method iteratively replaces the higher-order terms <italic>xyz</italic> with lower-order terms by introducing auxiliary binary variables <italic>w</italic>. Depending on the order in which variable terms are replaced, the QUBO formulation may vary in format and the number of binary variables, but the minimum point for the fixed HUBO remains unchanged.</p>
</sec>
</sec>
<sec id="s3">
<label>3</label>
<title>Join order cost as HUBO</title>
<p>In this section, we develop two higher-order unconstrained binary optimization (HUBO) problems that encode the cost function (<xref ref-type="disp-formula" rid="EQ2">Equation 2</xref>) for left-deep join order selection problems. We will later focus on the validity constraint separately. Since validity will be built on the cost formulation, we present the cost formulation first. Compared to previous quantum computing research on join order optimization, we formulate the optimization problem from the perspective of <italic>joins</italic>, instead of <italic>relations</italic> (<xref ref-type="bibr" rid="B57">Sch&#x000F6;nberger et al., 2023a</xref>). This represents a new conceptual angle to the problem, which makes the formulations substantially distinct. The other new viewpoint is to encode the costs into coefficients of the HUBO polynomial, instead of encoding them with slack variables. This eliminates the need to estimate costs and use additional variables or qubits for encoding in the problem formulation.</p>
<p>The monomials in the HUBO formulation identify a specific join order path. The coefficients in the formulation describe the intermediate costs. Activating combinations of binary variables enables us to compute total join order costs for various join orders through activated monomials. Thus, the cost HUBO is the sum of terms, and we show that the minimum of the polynomial corresponds to the cost of the optimal plan.</p>
<p>Given a query graph <italic>G</italic>, the number of required joins to create a valid left-deep join tree is |<italic>V</italic>| &#x02212; 1, where |<italic>V</italic>| is the number of nodes (i.e., relations or tables) in query graph <italic>G</italic>. This is easy to see since the first join is performed between two relations, and after that, every join includes one more relation until all the relations have been joined.</p>
<p>Our algorithm is designed to rank joins, and the ranking determines the order of the joins. This means a join (i.e., edge in the query graph <italic>G</italic>) has a rank 0 &#x02264; <italic>r</italic> &#x0003C; |<italic>V</italic>| &#x02212; 1 if the join should be performed after all the lower rank joins are performed. We need |<italic>V</italic>| &#x02212; 1 rank values to create a left-deep join order plan. Having |<italic>V</italic>| &#x02212; 1 rank values applies to left-deep join plans but not bushy ones. For bushy plans, we can join multiple relations simultaneously, meaning that some of the joins can have the same rank, i.e., appear at the same level in the join tree. It will be part of future research to tackle these cases.</p>
<p>Initially, any join, i.e., edge (<italic>R</italic><sub><italic>i</italic></sub>, <italic>R</italic><sub><italic>j</italic></sub>) &#x02208; <italic>G</italic>, can have any rank 0 &#x02264; <italic>r</italic> &#x0003C; |<italic>V</italic>| &#x02212; 1. Hence, we define the binary variables of our HUBO problems to be</p>
<disp-formula id="EQ10"><mml:math id="M13"><mml:mtable class="eqnarray" columnalign="left"><mml:mtr><mml:mtd><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup><mml:mo>&#x02208;</mml:mo><mml:mrow><mml:mo stretchy="false">{</mml:mo><mml:mrow><mml:mn>0</mml:mn><mml:mo>,</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mo stretchy="false">}</mml:mo></mml:mrow><mml:mo>,</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math><label>(8)</label></disp-formula>
<p>where the indices <italic>i</italic> and <italic>j</italic> refer to the edge (<italic>R</italic><sub><italic>i</italic></sub>, <italic>R</italic><sub><italic>j</italic></sub>) &#x02208; <italic>G</italic>, where <italic>R</italic><sub><italic>i</italic></sub> and <italic>R</italic><sub><italic>j</italic></sub> are relations and <italic>r</italic> denotes the rank. Hence, our model consists of (|<italic>V</italic>| &#x02212; 1)|<italic>E</italic>| binary variables since for every rank value 0 &#x02264; <italic>r</italic> &#x0003C; |<italic>V</italic>| &#x02212; 1, we have |<italic>E</italic>| many joins (edges) from which we can choose the join.</p>
<p>The interpretation of these binary variables is as follows: If <inline-formula><mml:math id="M14"><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:math></inline-formula>, then the join (<italic>R</italic><sub><italic>i</italic></sub>, <italic>R</italic><sub><italic>j</italic></sub>) should be performed at rank <italic>r</italic>. Now the join (<italic>R</italic><sub><italic>i</italic></sub>, <italic>R</italic><sub><italic>j</italic></sub>) is not necessarily between the relations <italic>R</italic><sub><italic>i</italic></sub> and <italic>R</italic><sub><italic>j</italic></sub> since at <italic>r</italic> &#x0003E; 0, the left relation is an intermediate result of type <italic>R</italic><sub><italic>k</italic><sub>1</sub></sub> &#x022C8; &#x02026; &#x022C8; <italic>R</italic><sub><italic>i</italic></sub> &#x022C8; &#x02026; &#x022C8; <italic>R</italic><sub><italic>k</italic><sub><italic>n</italic></sub></sub> for some indices <italic>k</italic><sub>1</sub>, &#x02026;, <italic>k</italic><sub><italic>n</italic></sub>. Therefore, each tuple (<italic>R</italic><sub><italic>i</italic></sub>, <italic>R</italic><sub><italic>j</italic></sub>) represents a logical join predicate defined in the query graph, not a physical join operation in an execution plan.</p>
<p>Example 3.1. Consider that we have a simple, complete query graph of four relations {0, 1, 2, 3}. Thus, we have |<italic>V</italic>| &#x0003D; 4 relations, |<italic>E</italic>| &#x0003D; 6 possible joins, and (|<italic>V</italic>| &#x02212; 1)|<italic>E</italic>| &#x0003D; 24 binary variables. Depending on the selectivities and cardinalities, an example solution that the model can return is <inline-formula><mml:math id="M15"><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mn>0</mml:mn><mml:mo>,</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msubsup><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:math></inline-formula>, <inline-formula><mml:math id="M16"><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:mn>2</mml:mn></mml:mrow><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msubsup><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:math></inline-formula>, and <inline-formula><mml:math id="M17"><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mn>2</mml:mn><mml:mo>,</mml:mo><mml:mn>3</mml:mn></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msubsup><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:math></inline-formula>, which gives us the left-deep join tree [[0, 1], 2], 3]. The solution is not unique; also, <inline-formula><mml:math id="M18"><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mn>0</mml:mn><mml:mo>,</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msubsup><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:math></inline-formula>, <inline-formula><mml:math id="M19"><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mn>0</mml:mn><mml:mo>,</mml:mo><mml:mn>2</mml:mn></mml:mrow><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msubsup><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:math></inline-formula>, and <inline-formula><mml:math id="M20"><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mn>2</mml:mn><mml:mo>,</mml:mo><mml:mn>3</mml:mn></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msubsup><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:math></inline-formula> produce the same plan with the same cost.</p>
<sec>
<label>3.1</label>
<title>Precise cost function as HUBO</title>
<p>After defining the binary variables of our optimization model, we describe how to encode the cost function as a higher-order unconstrained binary optimization problem, whose minimum corresponds to the optimal cost up to cross products for the left-deep join order selection problem. We describe the cost constraint first, as the validity constraints can be computed based on terms that we derive for the cost constraint. First, we demonstrate the intuition behind the construction with an example.</p>
<p>Example 3.2. Every join should be performed at exactly one rank for left-deep join trees. Starting from rank 0, let us say that we choose to perform a join between the relations <italic>R</italic><sub>1</sub> and <italic>R</italic><sub>2</sub>, obtaining <italic>R</italic><sub>1</sub> &#x022C8; <italic>R</italic><sub>2</sub>. The corresponding activated binary variable is <inline-formula><mml:math id="M21"><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:mn>2</mml:mn></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msubsup><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:math></inline-formula>. Based on the cost function in <xref ref-type="disp-formula" rid="EQ2">Equation 2</xref>, the cost of performing this join is <italic>f</italic><sub>1, 2</sub>|<italic>R</italic><sub>1</sub>||<italic>R</italic><sub>2</sub>|, where |<italic>R</italic><sub>1</sub>| and |<italic>R</italic><sub>2</sub>| are the cardinalities for the corresponding relations and <italic>f</italic><sub>1, 2</sub> is the selectivity. Thus, if we decide to make this join at this rank, we include the term</p>
<disp-formula id="E11"><mml:math id="M22"><mml:mtable columnalign="left"><mml:mtr><mml:mtd><mml:msub><mml:mrow><mml:mi>f</mml:mi></mml:mrow><mml:mrow><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo>|</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>||</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo>|</mml:mo><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:mn>2</mml:mn></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msubsup></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula>
<p>to the cost HUBO formulation. This example demonstrates that it is easy to encode the costs at rank 0, which correspond to linear variables in the cost HUBO.</p>
<p>Next, we assume the query graph gives us a join predicate with selectivity <italic>f</italic><sub>2, 3</sub> between the relations <italic>R</italic><sub>2</sub> and <italic>R</italic><sub>3</sub>. Now we ask how expensive it is to perform the join between the intermediate result <italic>R</italic><sub>1</sub> &#x022C8; <italic>R</italic><sub>2</sub> and relation <italic>R</italic><sub>3</sub>. By <xref ref-type="disp-formula" rid="EQ2">Equation 2</xref>, the cost of making this join is</p>
<disp-formula id="EQ12"><mml:math id="M23"><mml:mtable class="eqnarray" columnalign="left"><mml:mtr><mml:mtd><mml:msub><mml:mrow><mml:mi>f</mml:mi></mml:mrow><mml:mrow><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:msub><mml:mrow><mml:mi>f</mml:mi></mml:mrow><mml:mrow><mml:mn>2</mml:mn><mml:mo>,</mml:mo><mml:mn>3</mml:mn></mml:mrow></mml:msub><mml:mo>|</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>||</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo>||</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mn>3</mml:mn></mml:mrow></mml:msub><mml:mo>|</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math><label>(9)</label></disp-formula>
<p>assuming that there is no edge (<italic>R</italic><sub>1</sub>, <italic>R</italic><sub>3</sub>), which indicates that <italic>f</italic><sub>1, 3</sub> &#x0003D; 1 (Cartesian product). Note that this is not the total cost of performing all the joins but the cardinality of the resulting relation <italic>R</italic><sub>1</sub> &#x022C8; <italic>R</italic><sub>2</sub> &#x022C8; <italic>R</italic><sub>3</sub>. The left-deep join tree (<italic>R</italic><sub>1</sub> &#x022C8; <italic>R</italic><sub>2</sub>) &#x022C8; <italic>R</italic><sub>3</sub> should be selected if the following total cost function evaluates to a relatively small value.</p>
<disp-formula id="E13"><mml:math id="M24"><mml:mtable columnalign="left"><mml:mtr><mml:mtd><mml:msub><mml:mrow><mml:mi>f</mml:mi></mml:mrow><mml:mrow><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo>|</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>||</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo>|</mml:mo><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:mn>2</mml:mn></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msubsup><mml:mo>&#x0002B;</mml:mo><mml:msub><mml:mrow><mml:mi>f</mml:mi></mml:mrow><mml:mrow><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:msub><mml:mrow><mml:mi>f</mml:mi></mml:mrow><mml:mrow><mml:mn>2</mml:mn><mml:mo>,</mml:mo><mml:mn>3</mml:mn></mml:mrow></mml:msub><mml:mo>|</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msub><mml:mo>||</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msub><mml:mo>||</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mn>3</mml:mn></mml:mrow></mml:msub><mml:mo>|</mml:mo><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:mn>2</mml:mn></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msubsup><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mn>2</mml:mn><mml:mo>,</mml:mo><mml:mn>3</mml:mn></mml:mrow><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msubsup><mml:mo>.</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula>
<p>When the binary variables are active, i.e., <inline-formula><mml:math id="M25"><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mn>1</mml:mn><mml:mo>,</mml:mo><mml:mn>2</mml:mn></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msubsup><mml:mo>=</mml:mo><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mn>2</mml:mn><mml:mo>,</mml:mo><mml:mn>3</mml:mn></mml:mrow><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msubsup><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:math></inline-formula>, the previous function evaluates the total cost of performing the join (<italic>R</italic><sub>1</sub> &#x022C8; <italic>R</italic><sub>2</sub>) &#x022C8; <italic>R</italic><sub>3</sub>.</p>
<p>A key insight is that the cardinality in <xref ref-type="disp-formula" rid="EQ12">Equation 9</xref> depends only on the set of relations being joined, not the order in which they were joined. In other words, this means that the cardinality in <xref ref-type="disp-formula" rid="EQ12">Equation 9</xref> is the same for any join result that includes the relations <italic>R</italic><sub>1</sub>, <italic>R</italic><sub>2</sub>, and <italic>R</italic><sub>3</sub>, such as (<italic>R</italic><sub>1</sub> &#x022C8; <italic>R</italic><sub>3</sub>) &#x022C8; <italic>R</italic><sub>2</sub> and <italic>R</italic><sub>1</sub> &#x022C8; (<italic>R</italic><sub>2</sub> &#x022C8; <italic>R</italic><sub>3</sub>). This naturally generalizes to any number of relations. The total costs of these plans likely differ because intermediate steps have different costs. Intuitively, our HUBO model seeks the optimal configuration of joins to construct the full join tree, ensuring that the sum of the intermediate results is minimized.</p>
<p>Next, we formally describe the construction of the HUBO problem, which encodes the precise cost function for a complete left-deep join order selection problem that respects the structure of a given query graph <italic>G</italic>. The HUBO problem is recursively constructed with respect to the rank <italic>r</italic>. The construction of the HUBO problem becomes recursive because the definition of the cost function in <xref ref-type="disp-formula" rid="EQ2">Equation 2</xref> is recursive.</p>
<p><bold>Step <italic>r</italic> &#x0003D; 0</bold>. Let <italic>G</italic> &#x0003D; (<italic>V, E</italic>) be a query graph. By <xref ref-type="disp-formula" rid="EQ2">Equation 2</xref>, we include the costs of making the rank 0 joins to the cost HUBO. Thus, we add terms</p>
<disp-formula id="E14"><mml:math id="M26"><mml:mtable columnalign="left"><mml:mtr><mml:mtd><mml:mo>|</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>&#x022C8;</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mi>j</mml:mi></mml:mrow></mml:msub><mml:mo>|</mml:mo><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msubsup><mml:mo>=</mml:mo><mml:msub><mml:mrow><mml:mi>f</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mi>j</mml:mi></mml:mrow></mml:msub><mml:mo>|</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>||</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mi>j</mml:mi></mml:mrow></mml:msub><mml:mo>|</mml:mo><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msubsup><mml:mo>=</mml:mo><mml:msub><mml:mrow><mml:mi>&#x003B1;</mml:mi></mml:mrow><mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow></mml:msub><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msubsup><mml:mo>,</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula>
<p>for every join (<italic>R</italic><sub><italic>i</italic></sub>, <italic>R</italic><sub><italic>j</italic></sub>) &#x02208; <italic>E</italic>, where we denote &#x003B1;<sub>(<italic>i, j</italic>)</sub>: &#x0003D; <italic>f</italic><sub><italic>ij</italic></sub>|<italic>R</italic><sub><italic>i</italic></sub>||<italic>R</italic><sub><italic>j</italic></sub>| as the coefficient encoding the cost.</p>
<p><bold>Step <italic>r</italic> &#x0003D; 1</bold>. For clarity, we also show step <italic>r</italic> &#x0003D; 1. Assuming we have completed step <italic>r</italic> &#x0003D; 0, we consider adding variables of type <inline-formula><mml:math id="M27"><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msubsup></mml:math></inline-formula>. For every join (<italic>R</italic><sub><italic>i</italic></sub>, <italic>R</italic><sub><italic>j</italic></sub>) &#x02208; <italic>E</italic>, we select the adjacent joins <inline-formula><mml:math id="M28"><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow></mml:msub></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula> in the query graph. An adjacent join means that the joins share exactly one common relation. This creates quadratic terms of type <inline-formula><mml:math id="M29"><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msubsup><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup><mml:mo>,</mml:mo><mml:msup><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msubsup></mml:math></inline-formula> with coefficients of type</p>
<disp-formula id="E15"><mml:math id="M30"><mml:msubsup><mml:mrow><mml:mi>&#x003B1;</mml:mi></mml:mrow><mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi><mml:mo>,</mml:mo><mml:msup><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup><mml:mo>,</mml:mo><mml:msup><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msubsup><mml:mo>:</mml:mo><mml:mo>=</mml:mo><mml:msub><mml:mrow><mml:mi>f</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mi>j</mml:mi></mml:mrow></mml:msub><mml:msub><mml:mrow><mml:mi>f</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup><mml:msup><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow></mml:msub><mml:msub><mml:mrow><mml:mi>f</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup><mml:mi>j</mml:mi></mml:mrow></mml:msub><mml:msub><mml:mrow><mml:mi>f</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:msup><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow></mml:msub><mml:mo>|</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>||</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mi>j</mml:mi></mml:mrow></mml:msub><mml:mo>||</mml:mo><mml:msubsup><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msubsup><mml:mo>||</mml:mo><mml:msubsup><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msubsup><mml:mo>|</mml:mo><mml:mo>.</mml:mo></mml:math></disp-formula>
<p>So, we add terms <inline-formula><mml:math id="M31"><mml:msub><mml:mrow><mml:mi>&#x003B1;</mml:mi></mml:mrow><mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi><mml:mo>,</mml:mo><mml:msup><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup><mml:mo>,</mml:mo><mml:msup><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow></mml:msub><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msubsup><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup><mml:mo>,</mml:mo><mml:msup><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msubsup></mml:math></inline-formula> to the cost HUBO.</p>
<p><bold>Step for arbitrary <italic>r</italic></bold>. Next, we consider adding a general rank 0 &#x0003C; <italic>r</italic> &#x0003C; |<italic>V</italic>| &#x02212; 1 variables of form <inline-formula><mml:math id="M32"><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup><mml:mo>,</mml:mo><mml:msup><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup></mml:math></inline-formula> to the HUBO problem. The construction can be divided into three steps:</p>
<p><bold>1</bold>. We identify completed subplans. For this general case, we formalize the method using connected subgraphs of the query graph and the monomials consisting of the binary variables. Let <inline-formula><mml:math id="M33"><mml:mrow><mml:mi mathvariant="script">S</mml:mi></mml:mrow></mml:math></inline-formula> be the set of size <italic>r</italic> &#x02212; 1 connected subgraphs in the query graph so that every subgraph corresponds to terms that were generated at step <italic>r</italic> &#x02212; 1. The size of a subgraph is defined as the number of its vertices. Each such subgraph corresponds to a term that specifies a join order, resulting in an intermediate table containing exactly <italic>r</italic> &#x02212; 1 relations. This means that the HUBO problem, encoding the total cost up to this step, has the following form:</p>
<disp-formula id="E16"><mml:math id="M34"><mml:mtable columnalign="left"><mml:mtr><mml:mtd><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mstyle displaystyle="true"><mml:munder accentunder="false"><mml:mrow><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02208;</mml:mo><mml:mi>E</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:msub><mml:mrow><mml:mi>&#x003B1;</mml:mi></mml:mrow><mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow></mml:msub><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msubsup></mml:mrow><mml:mo>&#x0FE38;</mml:mo></mml:munder></mml:mstyle></mml:mrow><mml:mrow><mml:mtext class="textrm" mathvariant="normal">case&#x000A0;</mml:mtext><mml:mi>r</mml:mi><mml:mo>=</mml:mo><mml:mn>0</mml:mn></mml:mrow></mml:munder></mml:mstyle><mml:mo>&#x0002B;</mml:mo><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mstyle displaystyle="true"><mml:munder accentunder="false"><mml:mrow><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02208;</mml:mo><mml:mi>E</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msup><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup><mml:mo>,</mml:mo><mml:msup><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02208;</mml:mo><mml:mi>E</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:msub><mml:mrow><mml:mi>&#x003B1;</mml:mi></mml:mrow><mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi><mml:mo>,</mml:mo><mml:msup><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup><mml:mo>,</mml:mo><mml:msup><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow></mml:msub><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msubsup><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup><mml:mo>,</mml:mo><mml:msup><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msubsup></mml:mrow><mml:mo>&#x0FE38;</mml:mo></mml:munder></mml:mstyle></mml:mrow><mml:mrow><mml:mtext class="textrm" mathvariant="normal">case&#x000A0;</mml:mtext><mml:mi>r</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:munder></mml:mstyle><mml:mo>&#x0002B;</mml:mo><mml:mo>&#x02026;</mml:mo></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mtext>&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;</mml:mtext><mml:mo>&#x0002B;</mml:mo><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mstyle displaystyle="true"><mml:munder accentunder="false"><mml:mrow><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>S</mml:mi><mml:mo>&#x02208;</mml:mo><mml:mrow><mml:mi mathvariant="script">S</mml:mi></mml:mrow></mml:mrow></mml:munder></mml:mstyle><mml:msub><mml:mrow><mml:mi>&#x003B1;</mml:mi></mml:mrow><mml:mrow><mml:mi>S</mml:mi></mml:mrow></mml:msub><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x0220F;</mml:mo></mml:mrow><mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mi>j</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02208;</mml:mo><mml:mi>S</mml:mi><mml:mo>,</mml:mo><mml:mn>0</mml:mn><mml:mo>&#x02264;</mml:mo><mml:mi>k</mml:mi><mml:mo>&#x02264;</mml:mo><mml:mi>r</mml:mi><mml:mo>-</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:munder></mml:mstyle><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>k</mml:mi></mml:mrow></mml:msubsup></mml:mrow><mml:mo>&#x0FE38;</mml:mo></mml:munder></mml:mstyle></mml:mrow><mml:mrow><mml:mtext class="textrm" mathvariant="normal">case&#x000A0;</mml:mtext><mml:mi>r</mml:mi><mml:mo>-</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:munder></mml:mstyle><mml:mo>.</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula>
<p><bold>2</bold>. We construct the new HUBO monomials for rank <italic>r</italic>. For simplicity, we first focus on generating the next term without a coefficient &#x003B1;. Let <inline-formula><mml:math id="M35"><mml:mi>S</mml:mi><mml:mo>&#x02208;</mml:mo><mml:mrow><mml:mi mathvariant="script">S</mml:mi></mml:mrow></mml:math></inline-formula> be a fixed subgraph of the query graph. Let <inline-formula><mml:math id="M36"><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow></mml:msub></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02208;</mml:mo><mml:mi>E</mml:mi></mml:math></inline-formula> be an edge that is not part of the subgraph <italic>S</italic> but connected to it so that either <inline-formula><mml:math id="M37"><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow></mml:msub><mml:mo>&#x02208;</mml:mo><mml:mi>S</mml:mi></mml:math></inline-formula> or <inline-formula><mml:math id="M38"><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow></mml:msub><mml:mo>&#x02208;</mml:mo><mml:mi>S</mml:mi></mml:math></inline-formula> (but not both <inline-formula><mml:math id="M39"><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow></mml:msub><mml:mo>&#x02208;</mml:mo><mml:mi>S</mml:mi></mml:math></inline-formula>). This means we join exactly one new relation. For this fixed subgraph <italic>S</italic> and fixed join <inline-formula><mml:math id="M40"><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow></mml:msub></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>, we are going to add the following element to the cost HUBO:</p>
<disp-formula id="EQ17"><mml:math id="M41"><mml:mtable class="eqnarray" columnalign="left"><mml:mtr><mml:mtd><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mstyle displaystyle="true"><mml:munder accentunder="false"><mml:mrow><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x0220F;</mml:mo></mml:mrow><mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mi>j</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02208;</mml:mo><mml:mi>S</mml:mi><mml:mo>,</mml:mo><mml:mn>0</mml:mn><mml:mo>&#x02264;</mml:mo><mml:mi>k</mml:mi><mml:mo>&#x02264;</mml:mo><mml:mi>r</mml:mi><mml:mo>-</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:munder></mml:mstyle><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>k</mml:mi></mml:mrow></mml:msubsup></mml:mrow><mml:mo>&#x0FE38;</mml:mo></mml:munder></mml:mstyle></mml:mrow><mml:mrow><mml:mtext class="textrm" mathvariant="normal">term at rank&#x000A0;</mml:mtext><mml:mi>r</mml:mi><mml:mo>-</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:munder></mml:mstyle><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mstyle displaystyle="true"><mml:munder accentunder="false"><mml:mrow><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup><mml:mo>,</mml:mo><mml:msup><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup></mml:mrow><mml:mo>&#x0FE38;</mml:mo></mml:munder></mml:mstyle></mml:mrow><mml:mrow><mml:mtext class="textrm" mathvariant="normal">new variable at rank&#x000A0;</mml:mtext><mml:mi>r</mml:mi></mml:mrow></mml:munder></mml:mstyle></mml:mtd></mml:mtr></mml:mtable></mml:math><label>(10)</label></disp-formula>
<p>The new term is just the &#x0201C;old&#x0201D; term from the previous step multiplied by the new variable <inline-formula><mml:math id="M42"><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup><mml:mo>,</mml:mo><mml:msup><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup></mml:math></inline-formula>.</p>
<p><bold>3</bold>. We compute the coefficient for the new monomial. A coefficient in the HUBO formulation represents a cardinality of the intermediate relation formed by the set of joins encoded in the corresponding monomial. Consider the new induced subgraph <inline-formula><mml:math id="M43"><mml:msup><mml:mrow><mml:mi>S</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup><mml:mo>=</mml:mo><mml:mi>S</mml:mi><mml:mo>&#x0222A;</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow></mml:msub></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:mrow><mml:mo>}</mml:mo></mml:mrow></mml:math></inline-formula>. The new coefficient <inline-formula><mml:math id="M44"><mml:msub><mml:mrow><mml:mi>&#x003B1;</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>S</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow></mml:msub></mml:math></inline-formula> is easy to compute based on the subgraph <italic>S</italic> and the latest included join <inline-formula><mml:math id="M45"><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow></mml:msub></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>. Note that the induced subgraph <italic>S</italic>&#x02032; may contain new edges besides the latest included edge <inline-formula><mml:math id="M46"><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow></mml:msub></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>. However, the new coefficient for term (<xref ref-type="disp-formula" rid="EQ17">Equation 10</xref>) is</p>
<disp-formula id="EQ18"><mml:math id="M47"><mml:mtable class="eqnarray" columnalign="left"><mml:mtr><mml:mtd><mml:msub><mml:mrow><mml:mi>&#x003B1;</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>S</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x0220F;</mml:mo></mml:mrow><mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mi>j</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02208;</mml:mo><mml:msup><mml:mrow><mml:mi>S</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow></mml:munder></mml:mstyle><mml:msub><mml:mrow><mml:mi>f</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow></mml:msub><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x0220F;</mml:mo></mml:mrow><mml:mrow><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>&#x02208;</mml:mo><mml:msup><mml:mrow><mml:mi>S</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow></mml:munder></mml:mstyle><mml:mo>|</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>|</mml:mo><mml:mo>.</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math><label>(11)</label></disp-formula>
<p>This formula is the general expression of <xref ref-type="disp-formula" rid="EQ12">Equation 9</xref> in Example 3.2.</p>
<p>This recursive process is repeated until we reach rank <italic>r</italic> &#x0003D; |<italic>V</italic>| &#x02212; 2, at which point the generated monomials will represent all possible valid, complete left-deep join trees. The full cost HUBO is the sum of all terms generated at all ranks from 0 to |<italic>V</italic>| &#x02212; 2. The idea of how the terms are appended at rank 2 is visualized in <xref ref-type="fig" rid="F2">Figure 2</xref>. One of the final configurations is visualized in <xref ref-type="fig" rid="F3">Figure 3</xref>, which also shows how the terms are interpreted as join trees.</p>
<fig position="float" id="F2">
<label>Figure 2</label>
<caption><p>With relations 0, 1, and 2 already joined, relation 3 is the only option for left-deep plans. Two combinations arise based on whether edge (0, 2) or (1, 2) joins first. Coloring links graph variables to the monomials in HUBO.</p></caption>
<graphic mimetype="image" mime-subtype="tiff" xlink:href="fcomp-07-1649354-g0002.tif">
<alt-text content-type="machine-generated">Diagram illustrating a network with nodes labeled 0, 1, 2, 3, and 4, connected by arrows. Node 2 is a variable in generation, connected to nodes 0 and 1 by blue x0_(0,2) and red x1_(0,2) lines, and to node 3 by a gray arrow labeled x2_(2,3). A line extends from node 3 to node 4. An arrow from node 3 points downward, indicating the generation of two new terms to HUBO: x0_(0,2)x1_(1,2)x2_(2,3) and x0_(1,2)x1_(0,2)x2_(2,3).</alt-text>
</graphic>
</fig>
<fig position="float" id="F3">
<label>Figure 3</label>
<caption><p>One option as the final assignment for the binary variables in the query graph. The algorithm returns the corresponding join tree if the variables are selected as true. Coloring links between graph variables and the monomials in HUBO, as well as to the generated plan.</p></caption>
<graphic mimetype="image" mime-subtype="tiff" xlink:href="fcomp-07-1649354-g0003.tif">
<alt-text content-type="machine-generated">Diagram of a tree structure with nodes labeled 0 through 4. Node 0 is connected to node 2, marked &#x0201C;(0,2) at rank 0.&#x0201D; Node 1 connects to node 2 as &#x0201C;(1,2) at rank 1.&#x0201D; Node 2 links to node 3 as &#x0201C;(2,3) at rank 2,&#x0201D; and node 3 connects to node 4 as &#x0201C;(3,4) at rank 3.&#x0201D; An arrow points to &#x0201C;Term in HUBO&#x0201D; with variables (x0_(0,2)x1_(1,2) x2_(2,3) x3_(3,4)). Another arrow leads to &#x0201C;Join tree&#x0201D; notation [[[[0, 2], 1], 3], 4].</alt-text>
</graphic>
</fig>
<p>The concrete algorithm for generating the cost HUBO is presented in <xref ref-type="statement" rid="algo3">Algorithm 3</xref>. It inputs a query graph and outputs the cost HUBO. The keys in this dictionary are sets of relations, and the values are tuples consisting of a monomial and its coefficient, which define the HUBO polynomial for the problem.</p>
<statement content-type="algorithm" id="algo3">
<label>Algorithm 3</label>
<title>Construct monomials and coefficients for precise cost HUBO.</title>
<p><monospace><bold>Input:</bold> Query graph <italic>G</italic> &#x0003D; (<italic>V, E</italic>), selectivities <italic>f</italic><sub><italic>i, j</italic></sub> for (<italic>i, j</italic>) &#x02208; <italic>E</italic>, cardinalities |<italic>R</italic><sub><italic>i</italic></sub>| for <italic>i</italic> &#x02208; <italic>V</italic></monospace></p>
<p><monospace><bold>Output:</bold> Map <inline-formula><mml:math id="M48"><mml:mrow><mml:mi mathvariant="script">M</mml:mi></mml:mrow></mml:math></inline-formula> from subplans <italic>S</italic> to (monomial, coefficient) for <italic>H</italic><sub>cost</sub></monospace></p>
<p><monospace>1: Initialize an empty map <inline-formula><mml:math id="M49"><mml:mrow><mml:mi mathvariant="script">M</mml:mi></mml:mrow></mml:math></inline-formula></monospace></p>
<p><monospace>&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x022B3; Maps connected subsets <italic>S</italic> to (monomial, coefficient)</monospace></p>
<p><monospace>2: <bold>for each</bold> <italic>r</italic> <bold>in</bold> 0, &#x02026;, |<italic>V</italic>| &#x02212; 2 <bold>do</bold></monospace></p>
<p><monospace>3: &#x000A0;&#x000A0;&#x000A0;&#x000A0;<bold>for each</bold> edge <italic>e</italic> &#x0003D; (<italic>i, j</italic>) &#x02208; <italic>E</italic> <bold>do</bold></monospace></p>
<p><monospace>4: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<bold>if</bold> <italic>r</italic> &#x0003D; 0 <bold>then</bold></monospace></p>
<p><monospace>5: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<italic>S</italic> &#x02190; {<italic>i, j</italic>}</monospace></p>
<p><monospace>6: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<inline-formula><mml:math id="M50"><mml:mstyle class="text"><mml:mtext class="textrm" mathvariant="normal">monomial</mml:mtext></mml:mstyle><mml:mo>&#x02190;</mml:mo><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msubsup></mml:math></inline-formula></monospace></p>
<p><monospace>7: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x003B1;<sub><italic>S</italic></sub> &#x02190; <italic>f</italic><sub><italic>i, j</italic></sub>|<italic>R</italic><sub><italic>i</italic></sub>||<italic>R</italic><sub><italic>j</italic></sub>|</monospace></p>
<p><monospace>&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x022B3; <xref ref-type="disp-formula" rid="EQ18">Equation 11</xref> for 2-table join</monospace></p>
<p><monospace>8: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<inline-formula><mml:math id="M51"><mml:mrow><mml:mi mathvariant="script">M</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">[</mml:mo><mml:mrow><mml:mi>S</mml:mi></mml:mrow><mml:mo stretchy="false">]</mml:mo></mml:mrow><mml:mo>&#x02190;</mml:mo><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mstyle class="text"><mml:mtext class="textrm" mathvariant="normal">monomial</mml:mtext></mml:mstyle><mml:mo>,</mml:mo><mml:msub><mml:mrow><mml:mi>&#x003B1;</mml:mi></mml:mrow><mml:mrow><mml:mi>S</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula></monospace></p>
<p><monospace>9: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<bold>else</bold></monospace></p>
<p><monospace>10: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<bold>for each</bold> <italic>S</italic>&#x02032; with |<italic>S</italic>&#x02032;| &#x0003D; <italic>r</italic>&#x0002B;1 and <inline-formula><mml:math id="M52"><mml:msup><mml:mrow><mml:mi>S</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup><mml:mo>&#x02208;</mml:mo><mml:mrow><mml:mi mathvariant="script">M</mml:mi></mml:mrow></mml:math></inline-formula> <bold>do</bold></monospace></p>
<p><monospace>11: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<bold>if</bold> (<italic>i</italic> &#x02208; <italic>S</italic>&#x02032; <bold>and</bold> <italic>j</italic> &#x02209; <italic>S</italic>&#x02032;) <bold>or</bold> (<italic>j</italic> &#x02208; <italic>S</italic>&#x02032; <bold>and</bold> <italic>i</italic> &#x02209; <italic>S</italic>&#x02032;) <bold>then</bold></monospace></p>
<p><monospace>12: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<italic>S</italic> &#x02190; <italic>S</italic>&#x02032;&#x0222A;{<italic>i, j</italic>}</monospace></p>
<p><monospace>13: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<inline-formula><mml:math id="M53"><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>m</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>S</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mrow><mml:mi>&#x003B1;</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>S</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow></mml:msub></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02190;</mml:mo><mml:mrow><mml:mi mathvariant="script">M</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">[</mml:mo><mml:mrow><mml:msup><mml:mrow><mml:mi>S</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:math></inline-formula></monospace></p>
<p><monospace>14: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<inline-formula><mml:math id="M54"><mml:msub><mml:mrow><mml:mi>m</mml:mi></mml:mrow><mml:mrow><mml:mi>S</mml:mi></mml:mrow></mml:msub><mml:mo>&#x02190;</mml:mo><mml:msub><mml:mrow><mml:mi>m</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>S</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow></mml:msub><mml:mo>&#x000B7;</mml:mo><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup></mml:math></inline-formula></monospace></p>
<p><monospace>15: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x003B1;<sub><italic>S</italic></sub> &#x02190; (&#x0220F;<sub>(<italic>u, v</italic>) &#x02208; <italic>E</italic>[<italic>S</italic>]</sub><italic>f</italic><sub><italic>u, v</italic></sub>)(&#x0220F;<sub><italic>t</italic> &#x02208; <italic>V</italic>[<italic>S</italic>]</sub>|<italic>R</italic><sub><italic>t</italic></sub>|)</monospace></p>
<p><monospace>&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x022B3; <xref ref-type="disp-formula" rid="EQ18">Equation 11</xref>; <italic>E</italic>[<italic>S</italic>] edges, <italic>V</italic>[<italic>S</italic>] vertices</monospace></p>
<p><monospace>16: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<inline-formula><mml:math id="M55"><mml:mrow><mml:mi mathvariant="script">M</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">[</mml:mo><mml:mrow><mml:mi>S</mml:mi></mml:mrow><mml:mo stretchy="false">]</mml:mo></mml:mrow><mml:mo>&#x02190;</mml:mo><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>m</mml:mi></mml:mrow><mml:mrow><mml:mi>S</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mrow><mml:mi>&#x003B1;</mml:mi></mml:mrow><mml:mrow><mml:mi>S</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula></monospace></p>
<p><monospace>17: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<bold>end if</bold></monospace></p>
<p><monospace>18: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<bold>end for</bold></monospace></p>
<p><monospace>19: &#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;&#x000A0;<bold>end if</bold></monospace></p>
<p><monospace>20: &#x000A0;&#x000A0;&#x000A0;&#x000A0;<bold>end for</bold></monospace></p>
<p><monospace>21: <bold>end for</bold></monospace></p>
<p><monospace>22: <bold>return</bold> <inline-formula><mml:math id="M56"><mml:mrow><mml:mi mathvariant="script">M</mml:mi></mml:mrow></mml:math></inline-formula></monospace></p>
</statement>
</sec>
<sec>
<label>3.2</label>
<title>Encoding heuristic cost function as HUBO</title>
<p>While this formulation for the precise cost function is exact, its computational complexity grows rapidly. Therefore, a heuristic approach is often necessary. Thus, we have modified the generation of the cost function to include a greedy heuristic in the HUBO construction process (<xref ref-type="statement" rid="algo3">Algorithm 3</xref>) to include only those higher-order terms that are likely to introduce the least cost to the total cost function.</p>
<p>The idea behind the heuristic is the following: First, we again include all the rank 0 terms. When we start including rank 1 terms, we consider only those rank 0 terms whose cardinality (i.e., the coefficient &#x003B1;<sub>(<italic>i, j</italic>)</sub> in the HUBO objective) is minimal. We have included a tunable hyperparameter <italic>n</italic> that selects <italic>n</italic> terms with the smallest coefficients. Then, the HUBO construction continues with the selected subset of terms. With this heuristic, the size of the optimization problem is reduced remarkably, although we lose the guarantee of finding the optimal plan.</p>
<p>This heuristic is implemented by modifying <xref ref-type="statement" rid="algo3">Algorithm 3</xref>. Specifically, in line 7, instead of iterating over all subplans from the previous rank, we select only the top-<italic>n</italic> subplans with the smallest associated cost coefficients. In other words, we change line 7 to be &#x0201C;<italic>n</italic> many relations associated with the rank <italic>r</italic> &#x02212; 1 variable with the smallest coefficients&#x0201D;. We will later prove that this formulation produces at least as good a plan as the classical greedy algorithm and likely produces better plans for larger values of <italic>n</italic>. For sufficiently large <italic>n</italic>, this formulation reduces back to the first, precise cost HUBO formulation.</p>
</sec>
</sec>
<sec id="s4">
<label>4</label>
<title>Join order validity as HUBO</title>
<p>For a HUBO formulation to be effective, its objective function must be constructed so that the minimizing point also represents a valid solution. In this case, validity refers to the join tree&#x00027;s adherence to the query graph, as defined in the Background section. All valid solutions are usable, although they might not minimize the cost. In this section, we present two approaches to encoding the validity of solutions: cost function-dependent and cost function-independent. A cost function-dependent approach is easy to construct but produces a larger number of higher-order terms. The cost function-independent approach is closer to the standard QUBO formulations and identifies a set of constraints that the formulation must satisfy. The advantage of the second formulation is that its terms are primarily quadratic, which makes it easier to optimize in practice.</p>
<sec>
<label>4.1</label>
<title>Cost function-dependent validity</title>
<p>Considering the cost HUBO generation in the previous section, we have generated higher-order terms that encode valid join trees at rank <italic>r</italic> &#x0003D; |<italic>V</italic>| &#x02212; 2. After applying <xref ref-type="statement" rid="algo3">Algorithm 3</xref>, we can access these terms with <inline-formula><mml:math id="M57"><mml:mrow><mml:mi mathvariant="script">M</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">[</mml:mo><mml:mrow><mml:mi>V</mml:mi></mml:mrow><mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:math></inline-formula>, where the set <italic>V</italic> is the node set, i.e., the set of relations. Let us denote this set of terms as <inline-formula><mml:math id="M58"><mml:mi>H</mml:mi><mml:mo>:</mml:mo><mml:mo>=</mml:mo><mml:mrow><mml:mi mathvariant="script">M</mml:mi></mml:mrow><mml:mrow><mml:mo stretchy="false">[</mml:mo><mml:mrow><mml:mi>V</mml:mi></mml:mrow><mml:mo stretchy="false">]</mml:mo></mml:mrow></mml:math></inline-formula>. For example, one of the terms is represented in <xref ref-type="fig" rid="F2">Figure 2</xref>. The first validity constraint forces the model to select exactly one of these terms as true, which ensures that the final join tree contains all the relations.</p>
<sec>
<label>4.1.1</label>
<title>Select one valid plan</title>
<p>We use a generalized one-hot (or <italic>k</italic>-hot) encoding from QUBO formulations (<xref ref-type="bibr" rid="B36">Lucas, 2014</xref>; <xref ref-type="bibr" rid="B59">Sch&#x000F6;nberger et al., 2023c</xref>). The encoding constructs a constraint that reaches its minimum when precisely <italic>k</italic> variables are selected to be true from a given set of binary variables. In the generalized formulation, we construct an objective that is minimized when exactly <italic>k</italic> terms are selected as true from a set of higher-order terms. Let <italic>H</italic> be the set of higher-order terms at rank <italic>r</italic> &#x0003D; |<italic>V</italic>| &#x02212; 2. This functionality generalizes to higher-order cases with the following formulation:</p>
<disp-formula id="EQ19"><mml:math id="M59"><mml:mtable class="eqnarray" columnalign="left"><mml:mtr><mml:mtd><mml:msup><mml:mrow><mml:mrow><mml:mo stretchy="true">(</mml:mo><mml:mrow><mml:mn>1</mml:mn><mml:mo>-</mml:mo><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>h</mml:mi><mml:mo>&#x02208;</mml:mo><mml:mi>H</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:mi>h</mml:mi></mml:mrow><mml:mo stretchy="true">)</mml:mo></mml:mrow></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msup><mml:mo>,</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math><label>(12)</label></disp-formula>
<p>where <inline-formula><mml:math id="M60"><mml:mi>h</mml:mi><mml:mo>=</mml:mo><mml:msubsup><mml:mrow><mml:mo>&#x0220F;</mml:mo></mml:mrow><mml:mrow><mml:mi>r</mml:mi><mml:mo>=</mml:mo><mml:mn>0</mml:mn></mml:mrow><mml:mrow><mml:mo>|</mml:mo><mml:mi>V</mml:mi><mml:mo>|</mml:mo><mml:mo>-</mml:mo><mml:mn>2</mml:mn></mml:mrow></mml:msubsup><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:msub><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup></mml:math></inline-formula> for some indices <italic>i</italic><sub><italic>r</italic></sub> and <italic>j</italic><sub><italic>r</italic></sub> for <italic>r</italic> &#x0003D; 0, &#x02026;, |<italic>V</italic>| &#x02212; 2 that depend on the query graph. This polynomial is minimized at a value of 0 if and only if exactly one term <italic>h</italic> in the summation is equal to 1, thereby enforcing the selection of a single valid plan. A detailed proof is provided in the theoretical analysis section.</p>
</sec>
<sec>
<label>4.1.2</label>
<title>Every rank must appear exactly once in the solution</title>
<p>A challenge with this approach is that the model may produce solutions containing unnecessarily activated variables. For example, a variable <italic>x</italic> might be set to 1, but if it only appears in terms where another variable is 0 (e.g., <italic>xy</italic>, where <italic>y</italic> &#x0003D; 0), its activation has no impact on the final cost. Consider the plan in <xref ref-type="fig" rid="F2">Figure 2</xref>. The HUBO that encodes this plan would have the same minimum even if we set <inline-formula><mml:math id="M61"><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mn>0</mml:mn><mml:mo>,</mml:mo><mml:mn>2</mml:mn></mml:mrow><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msubsup><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:math></inline-formula> because this variable would always be multiplied by variables set to 0. While this can be solved with classical post-processing, and it does not affect the theoretical construction, we address it with an additional constraint. We include a constraint that every rank should appear exactly once in the solution. This is also an instance of one-hot encoding (<xref ref-type="bibr" rid="B17">D-Wave Systems Inc., 2024</xref>) and encoded with the following quadratic objective:</p>
<disp-formula id="EQ20"><mml:math id="M62"><mml:mtable class="eqnarray" columnalign="left"><mml:mtr><mml:mtd><mml:mstyle displaystyle="true"><mml:munderover accentunder="false" accent="false"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>r</mml:mi><mml:mo>=</mml:mo><mml:mn>0</mml:mn></mml:mrow><mml:mrow><mml:mrow><mml:mo>|</mml:mo><mml:mi>V</mml:mi><mml:mo>|</mml:mo></mml:mrow><mml:mo>-</mml:mo><mml:mn>2</mml:mn></mml:mrow></mml:munderover></mml:mstyle><mml:msup><mml:mrow><mml:mrow><mml:mo stretchy="true">(</mml:mo><mml:mrow><mml:mn>1</mml:mn><mml:mo>-</mml:mo><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mi>j</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02208;</mml:mo><mml:mi>E</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="true">)</mml:mo></mml:mrow></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msup><mml:mo>.</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math><label>(13)</label></disp-formula>
<p>The objective <italic>H</italic><sub>1</sub> is minimized when exactly one variable of type <inline-formula><mml:math id="M63"><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup></mml:math></inline-formula> is selected to be true for each 0 &#x02264; <italic>r</italic> &#x0003C; |<italic>V</italic>| &#x02212; 1. This constraint enforces the fundamental rule of left-deep plans: At each rank <italic>r</italic>, exactly one join must be selected. The inner summation counts the number of joins selected at rank r. The expression is minimized to 0 when this count is exactly 1, thus providing a constraint for each rank.</p>
</sec>
</sec>
<sec>
<label>4.2</label>
<title>Cost function-independent validity</title>
<p>The validity constraint in <xref ref-type="disp-formula" rid="EQ19">Equation 12</xref> produces higher-degree terms due to exponentiation to the power of two, which we might want to avoid. Hence, we develop join tree validity constraints independently from the cost function. Notably, these validity constraints are often quadratic, i.e., QUBOs, and are automatically supported by many solvers. Because we develop the theory considering the query graph&#x00027;s structure, we have slightly different constraints depending on the query graphs.</p>
<sec>
<label>4.2.1</label>
<title>Clique graphs</title>
<p><bold>Every rank must be selected exactly once in the solution</bold>. This first constraint was already presented in <xref ref-type="disp-formula" rid="EQ20">Equation 13</xref>.</p>
<p><bold>Select connected join tree</bold>. The second constraint encodes that we penalize cases that do not form a connected join tree. To achieve this, we include a constraint of the following form:</p>
<disp-formula id="EQ21"><mml:math id="M64"><mml:mtable class="eqnarray" columnalign="left"><mml:mtr><mml:mtd><mml:mstyle displaystyle="true"><mml:munderover accentunder="false" accent="false"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>r</mml:mi><mml:mo>=</mml:mo><mml:mn>0</mml:mn></mml:mrow><mml:mrow><mml:mrow><mml:mo>|</mml:mo><mml:mi>V</mml:mi><mml:mo>|</mml:mo></mml:mrow><mml:mo>-</mml:mo><mml:mn>2</mml:mn></mml:mrow></mml:munderover></mml:mstyle><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02208;</mml:mo><mml:mi>E</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msup><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup><mml:mo>,</mml:mo><mml:msup><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02208;</mml:mo><mml:mi>E</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:mi>C</mml:mi><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup><mml:mo>,</mml:mo><mml:msup><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mrow><mml:mi>r</mml:mi><mml:mo>&#x0002B;</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msubsup><mml:mo>,</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math><label>(14)</label></disp-formula>
<p>where we sum over the elements if the indices satisfy |{<italic>i, j</italic>} &#x02229; {<italic>i</italic>&#x02032;, <italic>j</italic>&#x02032;}| &#x02260; 1. This constraint penalizes two types of invalid sequences: (1) selecting the same join at two consecutive ranks and (2) selecting two joins at consecutive ranks that share no common relations. This encourages the model to select a new join that connects to the existing intermediate result, forming a connected graph.</p>
<p><bold>Result contains all the relations</bold>. The third constraint forces us to join all the relations. Our framework identifies joins as pairs of relations (<italic>R</italic><sub><italic>i</italic></sub>, <italic>R</italic><sub><italic>j</italic></sub>). This leads to one relation <italic>R</italic><sub><italic>i</italic></sub> appearing multiple times in variables, referring to different joins in a valid solution. An example of this is presented in <xref ref-type="fig" rid="F3">Figure 3</xref>, where relation 2 appears multiple times in the solution, consisting of joins such as (0, 2) and (1, 2). This third constraint encodes that we count the number of relations and require that the count is at least one for each relation. Counting relations involves a minimum of a logarithmic number of slack variables (the method to do the logarithmic encoding is presented in <xref ref-type="bibr" rid="B36">Lucas, 2014</xref>) in terms of relations. For technical simplicity, we present the less efficient but equivalent method here:</p>
<disp-formula id="EQ22"><mml:math id="M65"><mml:mtable class="eqnarray" columnalign="left"><mml:mtr><mml:mtd><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:msub><mml:mrow><mml:mi>R</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msub><mml:mo>&#x02208;</mml:mo><mml:mi>G</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:msup><mml:mrow><mml:mrow><mml:mo stretchy="true">(</mml:mo><mml:mrow><mml:mn>1</mml:mn><mml:mo>&#x0002B;</mml:mo><mml:mstyle displaystyle="true"><mml:munderover accentunder="false" accent="false"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>k</mml:mi><mml:mo>=</mml:mo><mml:mn>2</mml:mn></mml:mrow><mml:mrow><mml:mrow><mml:mo>|</mml:mo><mml:mi>V</mml:mi><mml:mo>|</mml:mo></mml:mrow><mml:mo>-</mml:mo><mml:mn>2</mml:mn></mml:mrow></mml:munderover></mml:mstyle><mml:mi>k</mml:mi><mml:msubsup><mml:mrow><mml:mi>y</mml:mi></mml:mrow><mml:mrow><mml:mi>k</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msubsup><mml:mo>-</mml:mo><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:mstyle displaystyle="true"><mml:munderover accentunder="false" accent="false"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>r</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mrow><mml:mo>|</mml:mo><mml:mi>V</mml:mi><mml:mo>|</mml:mo></mml:mrow><mml:mo>-</mml:mo><mml:mn>2</mml:mn></mml:mrow></mml:munderover></mml:mstyle><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="true">)</mml:mo></mml:mrow></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msup><mml:mo>.</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math><label>(15)</label></disp-formula>
<p>The constraint reaches zero if at least one variable of type <inline-formula><mml:math id="M66"><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup></mml:math></inline-formula> is true for each relation <italic>R</italic><sub><italic>i</italic></sub>. The constraint ensures that each relation <italic>R</italic><sub><italic>i</italic></sub> is included in at least one selected join. It uses slack variables <inline-formula><mml:math id="M67"><mml:msubsup><mml:mrow><mml:mi>y</mml:mi></mml:mrow><mml:mrow><mml:mi>k</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi></mml:mrow></mml:msubsup></mml:math></inline-formula> to encode the count of how many times a relation appears in the plan, penalizing cases where the count for a given relation is zero.</p>
</sec>
<sec>
<label>4.2.2</label>
<title>Chain, star, cycle, and tree graphs</title>
<p><bold>At every rank, we have performed rank</bold> <bold>&#x0002B;</bold> <bold>1 many joins</bold>. This constraint is related to the first validity constraint presented in the study by <xref ref-type="bibr" rid="B57">Sch&#x000F6;nberger et al. (2023a)</xref> and <xref ref-type="bibr" rid="B58">Sch&#x000F6;nberger et al. (2023b)</xref>. They present the constraint in terms of relations, whereas we have constructed it in terms of joins. The constraint encodes the number of joins we must perform cumulatively at each rank. In other words, when the rank is 0, we select one variable of type <inline-formula><mml:math id="M68"><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mn>0</mml:mn></mml:mrow></mml:msubsup></mml:math></inline-formula> to be true. When the rank is 1, we choose two variables of type <inline-formula><mml:math id="M69"><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mn>1</mml:mn></mml:mrow></mml:msubsup></mml:math></inline-formula> to be true. Formally, this constraint is</p>
<disp-formula id="EQ23"><mml:math id="M70"><mml:mtable class="eqnarray" columnalign="left"><mml:mtr><mml:mtd><mml:mstyle displaystyle="true"><mml:munderover accentunder="false" accent="false"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>r</mml:mi><mml:mo>=</mml:mo><mml:mn>0</mml:mn></mml:mrow><mml:mrow><mml:mrow><mml:mo>|</mml:mo><mml:mi>V</mml:mi><mml:mo>|</mml:mo></mml:mrow><mml:mo>-</mml:mo><mml:mn>2</mml:mn></mml:mrow></mml:munderover></mml:mstyle><mml:msup><mml:mrow><mml:mrow><mml:mo stretchy="true">(</mml:mo><mml:mrow><mml:mi>r</mml:mi><mml:mo>&#x0002B;</mml:mo><mml:mn>1</mml:mn><mml:mo>-</mml:mo><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02208;</mml:mo><mml:mi>E</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="true">)</mml:mo></mml:mrow></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msup><mml:mo>.</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math><label>(16)</label></disp-formula>
<p>The constraint is minimized at 0 when for each 0 &#x02264; <italic>r</italic> &#x0003C; |<italic>V</italic>| &#x02212; 1, we have selected exactly <italic>r</italic> &#x0002B; 1 variables of type <inline-formula><mml:math id="M71"><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup></mml:math></inline-formula> to be true.</p>
<p><bold>Include the previous joins in the proceeding ranks</bold>. This constraint is again similar to the second constraint presented in the study by <xref ref-type="bibr" rid="B57">Sch&#x000F6;nberger et al. (2023a)</xref> and <xref ref-type="bibr" rid="B58">Sch&#x000F6;nberger et al. (2023b)</xref>, except that we express the constraint using joins. If the join happened at rank <italic>r</italic>, it should be included in every proceeding rank &#x02265; <italic>r</italic>. In other words, we retain the information from the performed joins for subsequent ranks. This can be achieved with the following constraint:</p>
<disp-formula id="EQ24"><mml:math id="M72"><mml:mtable class="eqnarray" columnalign="left"><mml:mtr><mml:mtd><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02208;</mml:mo><mml:mi>E</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:mstyle displaystyle="true"><mml:munderover accentunder="false" accent="false"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>r</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mrow><mml:mo>|</mml:mo><mml:mi>V</mml:mi><mml:mo>|</mml:mo></mml:mrow><mml:mo>-</mml:mo><mml:mn>2</mml:mn></mml:mrow></mml:munderover></mml:mstyle><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi><mml:mo>-</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msubsup><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mn>1</mml:mn><mml:mo>-</mml:mo><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>.</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math><label>(17)</label></disp-formula>
<p>Now, if <inline-formula><mml:math id="M73"><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi><mml:mo>-</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msubsup></mml:math></inline-formula> is active, then the model favors the case that <inline-formula><mml:math id="M74"><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup></mml:math></inline-formula> is active too since in that case, <inline-formula><mml:math id="M75"><mml:mn>1</mml:mn><mml:mo>-</mml:mo><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup><mml:mo>=</mml:mo><mml:mn>0</mml:mn></mml:math></inline-formula>. If <inline-formula><mml:math id="M76"><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup><mml:mo>=</mml:mo><mml:mn>0</mml:mn></mml:math></inline-formula>, the term evaluates to 1, which penalizes the configuration.</p>
<p><bold>Respect query graph: chain, star, cycle</bold>. Since the cost functions are designed to respect structures of query graphs, we use the following constraint to encode the graph structure in chain, star, and cycle graphs:</p>
<disp-formula id="EQ25"><mml:math id="M77"><mml:mtable class="eqnarray" columnalign="left"><mml:mtr><mml:mtd><mml:mstyle displaystyle="true"><mml:munderover accentunder="false" accent="false"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>r</mml:mi><mml:mo>=</mml:mo><mml:mn>0</mml:mn></mml:mrow><mml:mrow><mml:mrow><mml:mo>|</mml:mo><mml:mi>V</mml:mi><mml:mo>|</mml:mo></mml:mrow><mml:mo>-</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:munderover></mml:mstyle><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02208;</mml:mo><mml:mi>E</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msup><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup><mml:mo>,</mml:mo><mml:msup><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02208;</mml:mo><mml:mi>E</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:mo>-</mml:mo><mml:mi>C</mml:mi><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup><mml:mo>,</mml:mo><mml:msup><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup><mml:mo>,</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math><label>(18)</label></disp-formula>
<p>where |{<italic>i, j</italic>} &#x02229; {<italic>i</italic>&#x02032;, <italic>j</italic>&#x02032;}| &#x0003D; 1, which means that the joins have to share exactly one relation. Setting the coefficient &#x02212;<italic>C</italic> as negative, we favor the cases when the joins share precisely one relation. This constraint is complementary to the constraint in <xref ref-type="disp-formula" rid="EQ21">Equation 14</xref>.</p>
<p><bold>Respect query graph: tree</bold>. Unfortunately, the previous constraint fails to encode the minimum for certain proper trees that contain nodes with at least three different degrees. The simplest, problematic tree shape is represented in <xref ref-type="fig" rid="F3">Figure 3</xref> (node 2 has degree 3, node 3 has degree 2, and the others have degree 1). The problem is that with the constraint in <xref ref-type="disp-formula" rid="EQ25">Equation 18</xref>, not all the join trees have the same minimum energy due to the different degrees of the nodes. To address this problem, we develop an alternative constraint:</p>
<disp-formula id="EQ26"><mml:math id="M78"><mml:mtable class="eqnarray" columnalign="left"><mml:mtr><mml:mtd><mml:mstyle displaystyle="true"><mml:munderover accentunder="false" accent="false"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>r</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mrow><mml:mo>|</mml:mo><mml:mi>V</mml:mi><mml:mo>|</mml:mo></mml:mrow><mml:mo>-</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:munderover></mml:mstyle><mml:msup><mml:mrow><mml:mrow><mml:mo stretchy="true">(</mml:mo><mml:mrow><mml:mi>r</mml:mi><mml:mo>-</mml:mo><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02208;</mml:mo><mml:mi>E</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msup><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup><mml:mo>,</mml:mo><mml:msup><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02208;</mml:mo><mml:mi>E</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup><mml:mo>,</mml:mo><mml:msup><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup></mml:mrow><mml:mo stretchy="true">)</mml:mo></mml:mrow></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msup><mml:mo>,</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math><label>(19)</label></disp-formula>
<p>where again we form the sum over the elements if the indices satisfy |{<italic>i, j</italic>} &#x02229; {<italic>i</italic>&#x02032;, <italic>j</italic>&#x02032;}| &#x0003D; 1. At every rank, this constraint selects <italic>r</italic>-many pairs of type <inline-formula><mml:math id="M79"><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:msup><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup><mml:mo>,</mml:mo><mml:msup><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup></mml:math></inline-formula> to be true. This forces the returned join tree to respect the query graph and be connected. This constraint is slightly more complex than the previous constraints, as it is not quadratic but a higher-order constraint that includes terms involving four variables. On the other hand, it does not introduce additional variables.</p>
<p><bold>Total HUBO and scaling cost and validity constraints</bold>. Finally, the cost HUBO and the validity encoding HUBO are summed together. Validity constraints are added to the objective function with a large penalty coefficient <italic>C</italic> &#x0003E; 0. The penalty <italic>C</italic> must be sufficiently large to ensure that any violation of the validity constraints creates a penalty larger than any potential savings in the cost function. This ensures that the cost <italic>H</italic><sub>cost</sub> and the validity objective <italic>H</italic><sub>val</sub> are scaled properly so that the model favors valid solutions over minimizing cost:</p>
<disp-formula id="E27"><mml:math id="M80"><mml:mrow><mml:msub><mml:mrow><mml:mi>H</mml:mi></mml:mrow><mml:mrow><mml:mtext class="textrm" mathvariant="normal">full</mml:mtext></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:msub><mml:mrow><mml:mi>H</mml:mi></mml:mrow><mml:mrow><mml:mtext class="textrm" mathvariant="normal">cost</mml:mtext></mml:mrow></mml:msub><mml:mo>&#x0002B;</mml:mo><mml:mi>C</mml:mi><mml:msub><mml:mrow><mml:mi>H</mml:mi></mml:mrow><mml:mrow><mml:mtext class="textrm" mathvariant="normal">val</mml:mtext></mml:mrow></mml:msub><mml:mo>.</mml:mo></mml:mrow></mml:math></disp-formula>
<p>A possible heuristic is to set <italic>C</italic> to be greater than the maximum value of <italic>H</italic><sub>cost</sub>. We found that setting <italic>C</italic> to the sum of all positive coefficients in <italic>H</italic><sub>cost</sub> worked consistently in our experiments.</p>
</sec>
</sec>
</sec>
<sec id="s5">
<label>5</label>
<title>Theoretical analysis</title>
<p>This section proves two theorems that provide bounds for the quality of the solutions that can theoretically be achieved with the proposed HUBO formulations for the join order selection problem. We introduced the classical baseline algorithms in Algorithms 1, 2. We emphasize that the HUBO formulations and the proofs are constructed to respect the underlying query graph. This means that the algorithms assume that cross products are expensive and could be avoided. Beneficial cross products can be explicitly encoded by adding an edge to the query graph with a selectivity of 1, and the proofs apply to cases with cross products by considering clique graphs where some of the selectivities are 1. While our formulation does not automatically discover such cross products, it can optimize them if they are provided, and this is a promising direction for future research.</p>
<p>By the definition of binary variables in <xref ref-type="disp-formula" rid="EQ10">Equation 8</xref>, we can prove the theorems by induction on the rank parameter <italic>r</italic> in the proposed HUBO constructions, as well as the iterations in the dynamic programming and greedy algorithms. Our proof strategy is to show that for every plan considered by the classical algorithms, there is a corresponding assignment in our HUBO formulation with the same cost, such that this assignment is also a minimizing solution to the HUBO problem.</p>
<p>Lemma 1. Let <italic>G</italic> &#x0003D; (<italic>V, E</italic>) be a query graph and let <italic>x</italic> &#x02208; {0, 1}<sup>|<italic>V</italic>| &#x02212; 1</sup> be a binary vector. Let <italic>H</italic><sub>val</sub> be the validity constraint consisting of constraints in <xref ref-type="disp-formula" rid="EQ19">Equations 12</xref>, <xref ref-type="disp-formula" rid="EQ20">13</xref>. If the cost-dependent validity constraint evaluates <italic>H</italic><sub>val</sub>(<italic>x</italic>) &#x0003D; 0, then vector <italic>x</italic> encodes a valid left-deep plan.</p>
<p><italic>Proof</italic>. First, assume that the cost-dependent validity constraint evaluates <italic>H</italic><sub>val</sub>(<italic>x</italic>) &#x0003D; 0. The first constraint in <xref ref-type="disp-formula" rid="EQ19">Equation 12</xref> is</p>
<disp-formula id="EQ28"><mml:math id="M81"><mml:mtable class="eqnarray" columnalign="left"><mml:mtr><mml:mtd><mml:msup><mml:mrow><mml:mrow><mml:mo stretchy="true">(</mml:mo><mml:mrow><mml:mn>1</mml:mn><mml:mo>-</mml:mo><mml:mstyle displaystyle="true"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>h</mml:mi><mml:mo>&#x02208;</mml:mo><mml:mi>H</mml:mi></mml:mrow></mml:munder></mml:mstyle><mml:mi>h</mml:mi></mml:mrow><mml:mo stretchy="true">)</mml:mo></mml:mrow></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msup><mml:mo>,</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math><label>(20)</label></disp-formula>
<p>where <inline-formula><mml:math id="M82"><mml:mi>h</mml:mi><mml:mo>=</mml:mo><mml:msubsup><mml:mrow><mml:mo>&#x0220F;</mml:mo></mml:mrow><mml:mrow><mml:mi>r</mml:mi><mml:mo>=</mml:mo><mml:mn>0</mml:mn></mml:mrow><mml:mrow><mml:mo>|</mml:mo><mml:mi>V</mml:mi><mml:mo>|</mml:mo><mml:mo>-</mml:mo><mml:mn>2</mml:mn></mml:mrow></mml:msubsup><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:msub><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup></mml:math></inline-formula> for some indices <italic>i</italic><sub><italic>r</italic></sub> and <italic>j</italic><sub><italic>r</italic></sub> for <italic>r</italic> &#x0003D; 0, &#x02026;, |<italic>V</italic>| &#x02212; 2 that depend on the query graph. This constraint is always non-negative since it is squared. It is positive, except when exactly one of the terms in the sum <inline-formula><mml:math id="M83"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>h</mml:mi><mml:mo>&#x02208;</mml:mo><mml:mi>H</mml:mi></mml:mrow></mml:munder><mml:mi>h</mml:mi></mml:math></inline-formula> is 1 when the constraint evaluates to 0. The sum <inline-formula><mml:math id="M84"><mml:munder class="msub"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>h</mml:mi><mml:mo>&#x02208;</mml:mo><mml:mi>H</mml:mi></mml:mrow></mml:munder><mml:mi>h</mml:mi></mml:math></inline-formula> evaluates to 1 when there is exactly one term <italic>h</italic> such that all the variables in the product <inline-formula><mml:math id="M85"><mml:mi>h</mml:mi><mml:mo>=</mml:mo><mml:msubsup><mml:mrow><mml:mo>&#x0220F;</mml:mo></mml:mrow><mml:mrow><mml:mi>r</mml:mi><mml:mo>=</mml:mo><mml:mn>0</mml:mn></mml:mrow><mml:mrow><mml:mo>|</mml:mo><mml:mi>V</mml:mi><mml:mo>|</mml:mo><mml:mo>-</mml:mo><mml:mn>2</mml:mn></mml:mrow></mml:msubsup><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:msub><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup></mml:math></inline-formula> are true. This combination of activated variables is the valid join tree that the objective function returns as a solution to the minimization problem.</p>
<p>By construction of <italic>H</italic> (<xref ref-type="statement" rid="algo3">Algorithm 3</xref>), every monomial <italic>h</italic> &#x02208; <italic>H</italic> encodes a left-deep sequence since</p>
<list list-type="bullet">
<list-item><p>The construction starts from a single edge at rank 0.</p></list-item>
<list-item><p>At rank <italic>r</italic> &#x0003E; 0, the construction extends the previously accumulated connected subgraph (plan) by one edge (join) that is incident to it, thereby adding exactly one new relation.</p></list-item>
<list-item><p>The construction reaches a subgraph whose vertex set is <italic>V</italic> at rank |<italic>V</italic>| &#x02212; 2.</p></list-item>
</list>
<p>These features define a valid left-deep plan. Therefore, the unique <italic>x</italic> selected above maps to a valid left-deep join plan that respects the query graph <italic>G</italic>.</p>
<p>Lemma 2. Let <italic>G</italic> &#x0003D; (<italic>V, E</italic>) be a query graph and let <italic>x</italic> &#x02208; {0, 1}<sup>|<italic>V</italic>| &#x02212; 1</sup> be a binary vector. If the cost-independent validity constraint evaluates <italic>H</italic><sub>val</sub>(<italic>x</italic>) &#x0003D; 0, then <italic>x</italic> encodes a valid left-deep plan.</p>
<p><italic>Proof</italic>. We divide the proof into two parts depending on the structure of the query graph.</p>
<p><bold>Clique graphs</bold>. In the case of clique graphs, the used validity constraints are as follows.</p>
<list list-type="order">
<list-item><p>There is precisely one join per rank, which is encoded with the constraint in <xref ref-type="disp-formula" rid="EQ20">Equation 13</xref>.</p></list-item>
<list-item><p>Consecutive joins must share exactly one relation and must not be identical or disjoint, which was encoded with the constraint in <xref ref-type="disp-formula" rid="EQ21">Equation 14</xref>.</p></list-item>
<list-item><p>Every relation appears at least once across all ranks, encoded in <xref ref-type="disp-formula" rid="EQ22">Equation 15</xref>.</p></list-item>
</list>
<p>Assume that the cost-independent validity constraint evaluates <italic>H</italic><sub>val</sub>(<italic>x</italic>) &#x0003D; 0. Since every constraint is non-negative, this means that they have to evaluate to 0. The first point ensures that there are exactly |<italic>V</italic>| &#x02212; 1 edges, and the second point ensures that the graph is connected. Thus, it is a tree. The last point ensures that every relation appears in the tree, and thus, it is a valid join tree.</p>
<p>The previous constraints are sufficient to also encode a left-deep join tree without additional constraints. For <italic>r</italic> &#x0003D; 0, the subgraph <italic>S</italic><sub>0</sub> contains two relations. The join <italic>e</italic><sub><italic>r</italic> &#x0002B; 1</sub> at rank <italic>r</italic> &#x0002B; 1 must connect to the join <italic>e</italic><sub><italic>r</italic></sub> at rank <italic>r</italic> by the constraint in <xref ref-type="disp-formula" rid="EQ21">Equation 14</xref>. Since the overall graph of joins is a tree, adding <italic>e</italic><sub><italic>r</italic> &#x0002B; 1</sub> cannot form a cycle with the previously selected joins. This implies that <italic>e</italic><sub><italic>r</italic> &#x0002B; 1</sub> must connect exactly one new relation to the set of relations <italic>S</italic><sub><italic>r</italic></sub>. Therefore, this progressive inclusion of exactly one new relation at each step defines a left-deep join plan.</p>
<p><bold>Chain, star, cycle, and tree graphs</bold>. In this case, the used validity constraints are as follows:</p>
<list list-type="order">
<list-item><p>We have a cumulative cardinality: at rank <italic>r</italic>, exactly <italic>r</italic> &#x0002B; 1 join variables are active, which is encoded by the constraint in <xref ref-type="disp-formula" rid="EQ23">Equation 16</xref>.</p></list-item>
<list-item><p>Join variables propagate across ranks: Once a join becomes active, it remains active, encoded in the constraint in <xref ref-type="disp-formula" rid="EQ24">Equation 17</xref>.</p></list-item>
<list-item><p>Enforce the correct adjacency at each rank. This is encoded with the constraints in <xref ref-type="disp-formula" rid="EQ25">Equations 18</xref>, <xref ref-type="disp-formula" rid="EQ26">19</xref>.</p></list-item>
</list>
<p>Define <inline-formula><mml:math id="M86"><mml:msub><mml:mrow><mml:mi>A</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msub><mml:mo>=</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02208;</mml:mo><mml:mi>E</mml:mi><mml:mo>&#x02223;</mml:mo><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mo>}</mml:mo></mml:mrow></mml:math></inline-formula> for each 0 &#x02264; <italic>r</italic> &#x02264; |<italic>V</italic>| &#x02212; 1. Assuming the previous points and <italic>H</italic><sub>val</sub>(<italic>x</italic>) &#x0003D; 0, we obtain <italic>A</italic><sub>0</sub> &#x02282; <italic>A</italic><sub>1</sub> &#x02282; &#x022EF; &#x02282; <italic>A</italic><sub>|<italic>V</italic>| &#x02212; 2</sub>. From the first point, it follows that |<italic>A</italic><sub><italic>r</italic></sub>| &#x0003D; <italic>r</italic> &#x0002B; 1, and the second point ensures that <italic>A</italic><sub><italic>r</italic> &#x02212; 1</sub> &#x02282; <italic>A</italic><sub><italic>r</italic></sub>. Thus, exactly one new join is added at each step. Moreover, the unique new join added when passing from <italic>A</italic><sub><italic>r</italic> &#x02212; 1</sub> to <italic>A</italic><sub><italic>r</italic></sub> shares exactly one endpoint with the current result.</p>
<p>Next, we consider the structure. For chain, star, and cycle queries, <xref ref-type="disp-formula" rid="EQ25">Equation 18</xref> gives a negative reward for each pair of same-rank joins that share exactly one endpoint. Summing over all pairs at rank <italic>r</italic> forces <italic>A</italic><sub><italic>r</italic></sub> to be a single connected component because disconnected elements are penalized. For proper trees, the constraint in <xref ref-type="disp-formula" rid="EQ26">Equation 19</xref> enforces exactly <italic>r</italic> adjacent pairs among the possibilities. That is a characterization of a tree on <italic>r</italic> &#x0002B; 2 vertices with <italic>r</italic> &#x0002B; 1 edges, which makes <italic>A</italic><sub><italic>r</italic></sub> connected and acyclic.</p>
<p>Since |<italic>A</italic><sub><italic>r</italic></sub>| &#x0003D; <italic>r</italic> &#x0002B; 1 and <italic>A</italic><sub><italic>r</italic></sub> is connected, it defines a tree. Since <italic>A</italic><sub><italic>r</italic></sub> &#x0003D; <italic>A</italic><sub><italic>r</italic> &#x02212; 1</sub> &#x0222A; {<italic>e</italic><sub><italic>r</italic></sub>} and <italic>A</italic><sub><italic>r</italic> &#x02212; 1</sub> is connected and acyclic, the only way how <italic>A</italic><sub><italic>r</italic></sub> is a tree is that the edge <italic>e</italic><sub><italic>r</italic></sub> shares exactly one endpoint with <italic>A</italic><sub><italic>r</italic> &#x02212; 1</sub>. This indicates that the plan is left-deep.</p>
<p>Theorem 3. Let <italic>G</italic> &#x0003D; (<italic>V, E</italic>) be a query graph. Define binary variables <inline-formula><mml:math id="M87"><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup><mml:mo>&#x02208;</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:mn>0</mml:mn><mml:mo>,</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mo>}</mml:mo></mml:mrow></mml:math></inline-formula> for each rank <italic>r</italic> &#x02208; {0, &#x02026;, |<italic>V</italic>| &#x02212; 1} and join edge (<italic>i, j</italic>) &#x02208; <italic>E</italic> as we defined in the context of binary variables in <xref ref-type="disp-formula" rid="EQ10">Equation 8</xref>. Let <italic>H</italic><sub>cost</sub> be the precise HUBO formulation obtained by <xref ref-type="statement" rid="algo3">Algorithm 3</xref> with the coefficients given by <xref ref-type="disp-formula" rid="EQ18">Equation 11</xref>. This means that every rank-<italic>r</italic> term corresponds to extending a connected subgraph by one adjacent edge and carries the cardinality-based cost contribution defined in <xref ref-type="disp-formula" rid="EQ1">Equation 1</xref>. Let <italic>H</italic><sub>val</sub> be any of the validity encodings in Section 4. Consider</p>
<disp-formula id="E29"><mml:math id="M88"><mml:mrow><mml:msub><mml:mrow><mml:mi>H</mml:mi></mml:mrow><mml:mrow><mml:mtext class="textrm" mathvariant="normal">full</mml:mtext></mml:mrow></mml:msub><mml:mo>:</mml:mo><mml:mo>=</mml:mo><mml:msub><mml:mrow><mml:mi>H</mml:mi></mml:mrow><mml:mrow><mml:mtext class="textrm" mathvariant="normal">cost</mml:mtext></mml:mrow></mml:msub><mml:mo>&#x0002B;</mml:mo><mml:mi>C</mml:mi><mml:msub><mml:mrow><mml:mi>H</mml:mi></mml:mrow><mml:mrow><mml:mtext class="textrm" mathvariant="normal">val</mml:mtext></mml:mrow></mml:msub><mml:mo>,</mml:mo></mml:mrow></mml:math></disp-formula>
<p>with a constant <italic>C</italic> &#x0003E; 0 chosen so that valid solutions are always preferred to any invalid ones. Let <italic>x</italic><sup>&#x022C6;</sup> minimize <italic>H</italic><sub>full</sub>. Then, the solution <italic>x</italic><sup>&#x022C6;</sup> encodes a valid left-deep plan <italic>T</italic><sup>&#x022C6;</sup> without cross products whose cost equals the cost from the DP algorithm without cross products:</p>
<disp-formula id="E30"><mml:math id="M89"><mml:mrow><mml:msub><mml:mrow><mml:mi>H</mml:mi></mml:mrow><mml:mrow><mml:mtext class="textrm" mathvariant="normal">cost</mml:mtext></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mo>&#x022C6;</mml:mo></mml:mrow></mml:msup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mi>C</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msup><mml:mrow><mml:mi>T</mml:mi></mml:mrow><mml:mrow><mml:mo>&#x022C6;</mml:mo></mml:mrow></mml:msup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>,</mml:mo></mml:mrow></mml:math></disp-formula>
<p>where <italic>C</italic>(&#x000B7;) is the recursive cost in <xref ref-type="disp-formula" rid="EQ2">Equation 2</xref>.</p>
<p><italic>Proof</italic>. The proof consists of three parts, which ensure the optimality and correctness: a bijection between valid DP plans and assignments without penalty, a rank-wise construction which identifies costs from <italic>H</italic><sub>cost</sub> with costs in the DP table, and penalty scaling to enforce feasibility.</p>
<p><bold>1</bold>. Based on Lemma 1 and Lemma 2, it suffices to show that the set</p>
<disp-formula id="EQ31"><mml:math id="M90"><mml:mtable class="eqnarray" columnalign="left"><mml:mtr><mml:mtd><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:mi>T</mml:mi><mml:mo>&#x02223;</mml:mo><mml:mi>T</mml:mi><mml:mtext class="textrm" mathvariant="normal">&#x000A0;is a left-deep plan adhering&#x000A0;</mml:mtext><mml:mi>G</mml:mi></mml:mrow><mml:mo>}</mml:mo></mml:mrow></mml:mtd></mml:mtr></mml:mtable></mml:math><label>(21)</label></disp-formula>
<p>is in a bijective relationship with the set</p>
<disp-formula id="EQ32"><mml:math id="M91"><mml:mtable class="eqnarray" columnalign="left"><mml:mtr><mml:mtd><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:mi>x</mml:mi><mml:mo>&#x02223;</mml:mo><mml:msub><mml:mrow><mml:mi>H</mml:mi></mml:mrow><mml:mrow><mml:mtext class="textrm" mathvariant="normal">val</mml:mtext></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mn>0</mml:mn></mml:mrow><mml:mo>}</mml:mo></mml:mrow><mml:mo>.</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math><label>(22)</label></disp-formula>
<p>Every left-deep plan <italic>T</italic> can be written as a sequence of joins (<italic>e</italic><sub>1</sub>, <italic>e</italic><sub>1</sub>, &#x02026;, <italic>e</italic><sub>|<italic>V</italic>| &#x02212; 1</sub>), where each <italic>e</italic><sub><italic>r</italic></sub> &#x0003D; (<italic>i</italic><sub><italic>r</italic></sub>, <italic>j</italic><sub><italic>r</italic></sub>) &#x02208; <italic>E</italic> joins exactly one new relation to the current connected join tree, and the join tree <italic>T</italic> adheres to the query graph <italic>G</italic> in the sense of Subsection 2.1. Define a mapping &#x003D5;:<italic>T</italic> &#x02192; {0, 1}<sup>|<italic>V</italic>| &#x02212; 1</sup> by</p>
<disp-formula id="E33"><mml:math id="M92"><mml:mrow><mml:mi>&#x003D5;</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msub><mml:mrow><mml:mi>e</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup><mml:mo>=</mml:mo><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:mtable style="text-align:axis;" equalrows="false" equalcolumns="false" class="array"><mml:mtr><mml:mtd><mml:mn>1</mml:mn><mml:mtext>&#x02003;</mml:mtext><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>i</mml:mi><mml:mo>,</mml:mo><mml:mi>j</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:msub><mml:mrow><mml:mi>e</mml:mi></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo></mml:mtd></mml:mtr><mml:mtr><mml:mtd><mml:mn>0</mml:mn><mml:mtext>&#x02003;</mml:mtext><mml:mtext class="textrm" mathvariant="normal">otherwise</mml:mtext><mml:mo>.</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:mrow></mml:mrow></mml:mrow></mml:math></disp-formula>
<p>By construction, the image &#x003D5;(<italic>T</italic>) &#x0003D; <italic>x</italic> satisfies the following properties:</p>
<list list-type="bullet">
<list-item><p>There is exactly one active variable at each rank <italic>r</italic> &#x02208; [1, |<italic>V</italic>| &#x02212; 1], which is forced by the constraint in <xref ref-type="disp-formula" rid="EQ20">Equation 13</xref>.</p></list-item>
<list-item><p>Consecutive joins share exactly one relation and extend connectivity, which is encoded with the constraint in <xref ref-type="disp-formula" rid="EQ21">Equation 14</xref>.</p></list-item>
<list-item><p>All the relations appear in the solution, which is encoded with the constraint in <xref ref-type="disp-formula" rid="EQ22">Equation 15</xref>.</p></list-item>
<list-item><p>Only edges (i.e., joins) in <italic>E</italic> are used, so there are no cross products. We called these constraints respecting the query graph <italic>G</italic>, and they were encoded in <xref ref-type="disp-formula" rid="EQ25">Equations 18</xref>, <xref ref-type="disp-formula" rid="EQ26">19</xref>.</p></list-item>
</list>
<p>Since this means that for the element &#x003D5;(<italic>T</italic>) &#x0003D; <italic>x</italic> every constraint is satisfied, we obtain that <italic>H</italic><sub>val</sub>(<italic>x</italic>) &#x0003D; 0. Conversely, for any <italic>x</italic> for which <italic>H</italic><sub>val</sub>(<italic>x</italic>) &#x0003D; 0, the previous constraints are satisfied, which means that exactly one join per rank is activated, and we obtain a connected left-deep sequence of edges in <italic>E</italic>. This decodes a plan <italic>T</italic> &#x0003D; &#x003D5;<sup>&#x02212;1</sup>(<italic>x</italic>). Thus, we obtain the bijection between sets in <xref ref-type="disp-formula" rid="EQ31">Equations 21</xref>, <xref ref-type="disp-formula" rid="EQ32">22</xref>.</p>
<p><bold>2</bold>. Next, we define a rank-wise invariant, which is proved to preserve the join order cost. The DP algorithm (without cross products) maintains, at iteration <italic>r</italic>, the DP table, which records all connected subplans with <italic>r</italic> &#x0002B; 1 relations. It also stores for each subplan its total cost under the cost function in <xref ref-type="disp-formula" rid="EQ2">Equation 2</xref>. Then, there exists an invariant <italic>I</italic>(<italic>r</italic>) as follows. After <xref ref-type="statement" rid="algo3">Algorithm 3</xref> has generated all terms up to rank <italic>r</italic>, for every connected subplan <italic>S</italic> with |<italic>S</italic>| &#x0003D; <italic>r</italic> &#x0002B; 1, there exist a set of variables <inline-formula><mml:math id="M93"><mml:msubsup><mml:mrow><mml:mrow><mml:mo>{</mml:mo><mml:mrow><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:msub><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>k</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>k</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mrow><mml:mi>k</mml:mi></mml:mrow></mml:msubsup></mml:mrow><mml:mo>}</mml:mo></mml:mrow></mml:mrow><mml:mrow><mml:mi>k</mml:mi><mml:mo>=</mml:mo><mml:mn>0</mml:mn></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msubsup></mml:math></inline-formula> such that</p>
<list list-type="order">
<list-item><p>The product term created by <xref ref-type="statement" rid="algo3">Algorithm 3</xref> for <italic>S</italic>,
<disp-formula id="E34"><mml:math id="M94"><mml:mrow><mml:mstyle displaystyle="true"><mml:munderover accentunder="false" accent="false"><mml:mrow><mml:mo>&#x0220F;</mml:mo></mml:mrow><mml:mrow><mml:mi>k</mml:mi><mml:mo>=</mml:mo><mml:mn>0</mml:mn></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:munderover></mml:mstyle><mml:msubsup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:msub><mml:mrow><mml:mi>i</mml:mi></mml:mrow><mml:mrow><mml:mi>k</mml:mi></mml:mrow></mml:msub><mml:mo>,</mml:mo><mml:msub><mml:mrow><mml:mi>j</mml:mi></mml:mrow><mml:mrow><mml:mi>k</mml:mi></mml:mrow></mml:msub></mml:mrow><mml:mrow><mml:mi>k</mml:mi></mml:mrow></mml:msubsup><mml:mo>,</mml:mo></mml:mrow></mml:math></disp-formula></p>
<p>is part of <italic>H</italic><sub>cost</sub>, and</p></list-item>
<list-item><p>the sum of coefficients contributed along this product (with &#x003B1;s from <xref ref-type="disp-formula" rid="EQ18">Equation 11</xref>) equals the DP total cost of <italic>S</italic>, i.e., the cumulative sum of intermediate cardinalities described by the cost function in <xref ref-type="disp-formula" rid="EQ2">Equation 2</xref>. Particularly, activating exactly these <italic>r</italic> &#x0002B; 1 variables yields <italic>H</italic><sub>cost</sub> equal to the DP table entry for <italic>S</italic>.</p></list-item>
</list>
<p><italic>Proof of the invariant</italic>. First, we consider the base case, when <italic>r</italic> &#x0003D; 0. By <xref ref-type="statement" rid="algo3">Algorithm 3</xref>, all the joins between the leaf relations are included in the cost function <italic>H</italic><sub>cost</sub>: &#x003B1;<sub>(<italic>i, j</italic>)</sub> &#x0003D; <italic>f</italic><sub><italic>i, j</italic></sub>|<italic>R</italic><sub><italic>i</italic></sub>||<italic>R</italic><sub><italic>j</italic></sub>|, which is exactly the DP cost of that binary join. Thus, <italic>I</italic>(0) holds.</p>
<p>Inductive step. Assume that <italic>I</italic>(<italic>r</italic> &#x02212; 1) holds. This means that there exists a connected subgraph <italic>S</italic><sub>prev</sub> of size <italic>r</italic>. Fix a connected subplan <italic>S</italic> of size <italic>r</italic> &#x0002B; 1. By construction, <xref ref-type="statement" rid="algo3">Algorithm 3</xref> forms <italic>S</italic> by extending <italic>S</italic><sub>prev</sub> with an adjacent edge (<italic>i</italic>&#x02032;, <italic>j</italic>&#x02032;) &#x02208; <italic>E</italic> that adds exactly one new relation. The new coefficient attached to this extension is &#x003B1;<sub><italic>S</italic></sub>, which is computed with <xref ref-type="disp-formula" rid="EQ18">Equation 11</xref>. This is precisely the cardinality, i.e., cost for the intermediate result after adding the (<italic>i</italic>&#x02032;, <italic>j</italic>&#x02032;) join. Summing this with the previously accumulated coefficients for <italic>S</italic><sub>prev</sub>, which exists by the induction assumption, gives exactly the DP total cost for <italic>S</italic>. Hence, <italic>I</italic>(<italic>r</italic>) holds.</p>
<p>Thus, for any left-deep plan <italic>T</italic> and <italic>x</italic> &#x0003D; &#x003D5;(<italic>T</italic>), when applying <italic>I</italic>(|<italic>V</italic>| &#x02212; 2), we obtain</p>
<disp-formula id="EQ35"><mml:math id="M95"><mml:mtable class="eqnarray" columnalign="left"><mml:mtr><mml:mtd><mml:msub><mml:mrow><mml:mi>H</mml:mi></mml:mrow><mml:mrow><mml:mtext class="textrm" mathvariant="normal">cost</mml:mtext></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mi>C</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>T</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>.</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math><label>(23)</label></disp-formula>
<p><bold>3</bold>. Finally, we consider optimality under the penalty constraint. We choose the constant <italic>C</italic> so that any violation of the validity constraint <italic>H</italic><sub>val</sub> raises the objective by at least the maximum possible variation of <italic>H</italic><sub>cost</sub>. Since every term in <italic>H</italic><sub>cost</sub> is positive, the simple choice for this is <italic>C</italic>: &#x0003D; <italic>H</italic><sub>cost</sub>(<bold>1</bold>), where <bold>1</bold> &#x0003D; (1, &#x02026;, 1). Then, any minimizer <italic>x</italic><sup>&#x022C6;</sup> of <italic>H</italic><sub>full</sub> must satisfy <inline-formula><mml:math id="M96"><mml:msub><mml:mrow><mml:mi>H</mml:mi></mml:mrow><mml:mrow><mml:mstyle class="text"><mml:mtext class="textrm" mathvariant="normal">val</mml:mtext></mml:mstyle></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mo>&#x022C6;</mml:mo></mml:mrow></mml:msup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mn>0</mml:mn></mml:math></inline-formula>. This means that <italic>x</italic><sup>&#x022C6;</sup> is valid and corresponds to some left-deep plan <italic>T</italic><sup>&#x022C6;</sup>, which we showed earlier.</p>
<p>Among such valid assignments, minimizing <italic>H</italic><sub>full</sub> becomes identical to minimizing <italic>H</italic><sub>cost</sub>. Restricting to valid <italic>x</italic> &#x0003D; &#x003D5;(<italic>T</italic>) gives <italic>H</italic><sub>cost</sub>(<italic>x</italic>) &#x0003D; <italic>C</italic>(<italic>T</italic>), as we pointed out in <xref ref-type="disp-formula" rid="EQ35">Equation 23</xref>. Therefore, <italic>x</italic><sup>&#x022C6;</sup> encodes a plan <italic>T</italic><sup>&#x022C6;</sup> whose cost is minimal among all left-deep plans without cross products. This is exactly the DP optimum without cross products: <inline-formula><mml:math id="M97"><mml:msub><mml:mrow><mml:mi>H</mml:mi></mml:mrow><mml:mrow><mml:mstyle class="text"><mml:mtext class="textrm" mathvariant="normal">cost</mml:mtext></mml:mstyle></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mo>&#x022C6;</mml:mo></mml:mrow></mml:msup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mi>C</mml:mi><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msup><mml:mrow><mml:mi>T</mml:mi></mml:mrow><mml:mrow><mml:mo>&#x022C6;</mml:mo></mml:mrow></mml:msup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow></mml:math></inline-formula>. This finalizes the proof.</p>
<p>Theorem 4. Let <italic>H</italic><sub>cost</sub> be the heuristic method&#x00027;s cost HUBO defined in subsection 3.2. Let <italic>x</italic><sup>&#x022C6;</sup> be a minimizer of <italic>H</italic><sub>cost</sub>. Then, <italic>H</italic><sub>cost</sub>(<italic>x</italic>) &#x02264; <italic>C</italic><sub>greedy</sub>, i.e., the cost from the greedy algorithm gives an upper bound for the cost from the heuristic algorithm.</p>
<p><italic>Proof</italic>. We use the same rank index <italic>r</italic> &#x02208; [0, |<italic>V</italic>| &#x02212; 2] as in the previous theorem, and use the same cost&#x02013;coefficient mapping defined in <xref ref-type="disp-formula" rid="EQ18">Equation 11</xref>. We again prove an invariant with respect to <italic>r</italic> as follows.</p>
<p>Invariant: For each rank <italic>r</italic>, the greedy algorithm&#x00027;s partial plan, <italic>T</italic><sub><italic>r</italic></sub>, is contained within the set of partial plans (the frontier) maintained by the heuristic HUBO construction.</p>
<p>Base case (<italic>r</italic> &#x0003D; 0): The heuristic algorithm includes all leaf joins at rank 0, so it contains the cheapest leaf join chosen by the classical greedy algorithm.</p>
<p>Inductive step: Assume the invariant holds for rank <italic>r</italic> &#x02212; 1, meaning <italic>T</italic><sub><italic>r</italic> &#x02212; 1</sub> is in the heuristic&#x00027;s frontier. The greedy algorithm extends <italic>T</italic><sub><italic>r</italic> &#x02212; 1</sub> by selecting the adjacent relation that minimizes the local cost increment. According to <xref ref-type="disp-formula" rid="EQ18">Equation 11</xref>, these local increments are precisely the &#x003B1;-coefficients for the valid rank-<italic>r</italic> extensions of <italic>T</italic><sub><italic>r</italic> &#x02212; 1</sub> in the HUBO formulation.</p>
<p>At rank <italic>r</italic>, the heuristic selects the top extensions based on the smallest coefficients. Since the greedy choice corresponds to the extension with the smallest increment (and thus smallest coefficient), it is guaranteed to be selected by the heuristic. Thus, the partial plan <italic>T</italic><sub><italic>r</italic></sub> is included in the heuristic&#x00027;s frontier, completing the induction.</p>
<p>Because the heuristic frontier contains the entire greedy path <italic>T</italic><sub>0</sub>, &#x02026;, <italic>T</italic><sub>|<italic>V</italic>| &#x02212; 2</sub> and the HUBO objective function sums the same local increment that the greedy algorithm accumulates along that path, there exists a feasible assignment <italic>x</italic>&#x02032; whose value equals the cost <italic>C</italic><sub>greedy</sub> from the classical greedy algorithm. The minimizer <italic>x</italic><sup>&#x022C6;</sup> of <italic>H</italic><sub>cost</sub> among valid plans cannot therefore do any worse, and we obtain</p>
<disp-formula id="E36"><mml:math id="M98"><mml:mtable columnalign="left"><mml:mtr><mml:mtd><mml:msub><mml:mrow><mml:mi>H</mml:mi></mml:mrow><mml:mrow><mml:mtext class="textrm" mathvariant="normal">cost</mml:mtext></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>&#x02264;</mml:mo><mml:msub><mml:mrow><mml:mi>H</mml:mi></mml:mrow><mml:mrow><mml:mtext class="textrm" mathvariant="normal">cost</mml:mtext></mml:mrow></mml:msub><mml:mrow><mml:mo stretchy="false">(</mml:mo><mml:mrow><mml:msup><mml:mrow><mml:mi>x</mml:mi></mml:mrow><mml:mrow><mml:mi>&#x02032;</mml:mi></mml:mrow></mml:msup></mml:mrow><mml:mo stretchy="false">)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:msub><mml:mrow><mml:mi>C</mml:mi></mml:mrow><mml:mrow><mml:mtext class="textrm" mathvariant="normal">greedy</mml:mtext></mml:mrow></mml:msub><mml:mo>.</mml:mo></mml:mtd></mml:mtr></mml:mtable></mml:math></disp-formula>
<sec>
<label>5.1</label>
<title>Complexity analysis</title>
<p>Here, we consider the computational complexities of the proposed algorithms. The join order problem with the cost model in <xref ref-type="disp-formula" rid="EQ2">Equation 2</xref> is generally NP-hard (<xref ref-type="bibr" rid="B12">Cluet and Moerkotte, 1995</xref>). The time complexity of dynamic programming algorithm depends on the query graph, the type of the dynamic programming algorithm, the type of the returned join plan (left-deep, zigzag, bushy, etc.), and whether cross products are included (<xref ref-type="bibr" rid="B39">Moerkotte and Neumann, 2006</xref>). The computational complexity ranges from <italic>O</italic>(3<sup>|<italic>V</italic>|</sup>) to linear. More precisely, the dynamic programming algorithm in this work is based on <xref ref-type="statement" rid="algo1">Algorithm 1</xref>. The complexity analysis of this algorithm shows that the worst-case running time is <italic>O</italic>(2<sup>|<italic>V</italic>|</sup>) for clique graphs (<xref ref-type="bibr" rid="B45">Neumann and Gubichev, 2014</xref>). Note that this is for left-deep trees, whereas the similar algorithm for finding bushy plans has complexity <italic>O</italic>(3<sup>|<italic>V</italic>|</sup>) (<xref ref-type="bibr" rid="B45">Neumann and Gubichev, 2014</xref>).</p>
<p>Similarly, the time complexity of the greedy algorithm in <xref ref-type="statement" rid="algo2">Algorithm 2</xref> depends on the structure of the query graph. The algorithm first evaluates the join between every pair of relations with respect to the query graph, requiring at most <italic>O</italic>(|<italic>V</italic>|<sup>2</sup>) steps. The greedy algorithm continues to evaluate the current cheapest plan with all the relations, which leads to a final time complexity of <italic>O</italic>(|<italic>V</italic>|<sup>2</sup>).</p>
<p>The complexity of solving HUBO and QUBO-based problems on quantum and classical hardware can be divided into multiple steps. The HUBO and QUBO problems are theoretically NP-complete problems (<xref ref-type="bibr" rid="B36">Lucas, 2014</xref>; <xref ref-type="bibr" rid="B8">Boros and Hammer, 2002</xref>). In practice, their difficulty also depends on the number of variables, the number of terms, the degree of the terms, the range of the coefficients, and how close the ground state is to the first excited state. For this HUBO formulation, the degree of the terms is at most the number of relations in the query. The cardinalities and selectivities of the relational database instance fully define the range of the coefficients. In the following, we will analyze the number of variables and the number of terms relying on the description of <xref ref-type="statement" rid="algo3">Algorithm 3</xref>.</p>
<sec>
<label>5.1.1</label>
<title>Complexity of HUBO construction</title>
<p>The complexity of <xref ref-type="statement" rid="algo3">Algorithm 3</xref> depends on the query graph. The outer loop over ranks runs for <italic>r</italic> &#x0003D; 0, &#x02026;, |<italic>V</italic>| &#x02212; 2. When <italic>r</italic> &#x0003D; 0, the algorithm performs |<italic>E</italic>| steps. When <italic>r</italic> &#x0003E; 0, the algorithm performs the following. Let <inline-formula><mml:math id="M99"><mml:mo>|</mml:mo><mml:msub><mml:mrow><mml:mrow><mml:mi mathvariant="script">H</mml:mi></mml:mrow></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msub><mml:mo>|</mml:mo></mml:math></inline-formula> denote the set of all connected subgraphs with exactly <italic>r</italic> &#x0002B; 1 vertices at rank <italic>r</italic>. At each rank <italic>r</italic> &#x0003E; 0, the algorithm loops over all |<italic>E</italic>| edges, and for each edge, iterates over the set of partial plans in <inline-formula><mml:math id="M100"><mml:msub><mml:mrow><mml:mrow><mml:mi mathvariant="script">H</mml:mi></mml:mrow></mml:mrow><mml:mrow><mml:mi>r</mml:mi><mml:mo>-</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:msub></mml:math></inline-formula> to test whether the edge can extend the subplan by one relation. Each such check and possible extension costs <italic>O</italic>(1) time. Hence, the total runtime is</p>
<disp-formula id="E37"><mml:math id="M101"><mml:mrow><mml:mi>O</mml:mi><mml:mrow><mml:mo stretchy="true">(</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo><mml:mi>E</mml:mi><mml:mo>|</mml:mo><mml:mo>&#x0002B;</mml:mo><mml:mstyle displaystyle="true"><mml:munderover accentunder="false" accent="false"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>r</mml:mi><mml:mo>=</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mrow><mml:mo>|</mml:mo><mml:mi>V</mml:mi><mml:mo>|</mml:mo></mml:mrow><mml:mo>-</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:munderover></mml:mstyle><mml:mo>|</mml:mo><mml:mi>E</mml:mi><mml:mo>|</mml:mo><mml:mo>&#x000B7;</mml:mo><mml:mo>|</mml:mo><mml:msub><mml:mrow><mml:mrow><mml:mi mathvariant="script">H</mml:mi></mml:mrow></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msub><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mo stretchy="true">)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mi>O</mml:mi><mml:mrow><mml:mo stretchy="true">(</mml:mo><mml:mrow><mml:mstyle displaystyle="true"><mml:munderover accentunder="false" accent="false"><mml:mrow><mml:mo>&#x02211;</mml:mo></mml:mrow><mml:mrow><mml:mi>r</mml:mi><mml:mo>=</mml:mo><mml:mn>0</mml:mn></mml:mrow><mml:mrow><mml:mrow><mml:mo>|</mml:mo><mml:mi>V</mml:mi><mml:mo>|</mml:mo></mml:mrow><mml:mo>-</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:munderover></mml:mstyle><mml:mo>|</mml:mo><mml:mi>E</mml:mi><mml:mo>|</mml:mo><mml:mo>&#x000B7;</mml:mo><mml:mo>|</mml:mo><mml:msub><mml:mrow><mml:mrow><mml:mi mathvariant="script">H</mml:mi></mml:mrow></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msub><mml:mo stretchy="false">|</mml:mo></mml:mrow><mml:mo stretchy="true">)</mml:mo></mml:mrow><mml:mo>.</mml:mo></mml:mrow></mml:math></disp-formula>
<p>Thus, we see that the total performance depends on the growth of the term <inline-formula><mml:math id="M102"><mml:mo>|</mml:mo><mml:msub><mml:mrow><mml:mrow><mml:mi mathvariant="script">H</mml:mi></mml:mrow></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msub><mml:mo>|</mml:mo></mml:math></inline-formula>. Worst-case complexity is achieved in a clique query graph, where every subset of <italic>r</italic> &#x0002B; 1 vertices forms a connected subgraph, so <inline-formula><mml:math id="M103"><mml:mo>|</mml:mo><mml:msub><mml:mrow><mml:mrow><mml:mi mathvariant="script">H</mml:mi></mml:mrow></mml:mrow><mml:mrow><mml:mi>r</mml:mi></mml:mrow></mml:msub><mml:mo>|</mml:mo><mml:mo>=</mml:mo><mml:mo>(</mml:mo><mml:mfrac linethickness="0.0pt"><mml:mrow><mml:mo>|</mml:mo><mml:mi>V</mml:mi><mml:mo>|</mml:mo></mml:mrow><mml:mrow><mml:mi>r</mml:mi><mml:mo>&#x0002B;</mml:mo><mml:mn>1</mml:mn></mml:mrow></mml:mfrac><mml:mo>)</mml:mo></mml:math></inline-formula>. Substituting into the bound above gives</p>
<disp-formula id="E38"><mml:math id="M104"><mml:mrow><mml:mi>O</mml:mi><mml:mrow><mml:mo stretchy="true">(</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo><mml:mi>E</mml:mi><mml:mo>|</mml:mo><mml:mo>&#x000B7;</mml:mo><mml:msup><mml:mrow><mml:mn>2</mml:mn></mml:mrow><mml:mrow><mml:mo>|</mml:mo><mml:mi>V</mml:mi><mml:mo>|</mml:mo></mml:mrow></mml:msup></mml:mrow><mml:mo stretchy="true">)</mml:mo></mml:mrow><mml:mo>=</mml:mo><mml:mi>O</mml:mi><mml:mrow><mml:mo stretchy="true">(</mml:mo><mml:mrow><mml:mo stretchy="false">|</mml:mo><mml:mi>V</mml:mi><mml:msup><mml:mrow><mml:mo>|</mml:mo></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:msup><mml:mo>&#x000B7;</mml:mo><mml:msup><mml:mrow><mml:mn>2</mml:mn></mml:mrow><mml:mrow><mml:mo>|</mml:mo><mml:mi>V</mml:mi><mml:mo>|</mml:mo></mml:mrow></mml:msup></mml:mrow><mml:mo stretchy="true">)</mml:mo></mml:mrow><mml:mo>.</mml:mo></mml:mrow></mml:math></disp-formula>
<p>Thus, <xref ref-type="statement" rid="algo3">Algorithm 3</xref> has exponential time complexity in the worst case, which matches the combinatorial complexity of the dynamic programming algorithm for join-order selection.</p>
<p>For other query graphs, the number of connected subsets is smaller. It is sufficient to consider only subtrees since <xref ref-type="statement" rid="algo3">Algorithm 3</xref> enumerates only connected subgraphs that are left-deep plans, which are trees. It was proved that the number of subtrees for chains is <inline-formula><mml:math id="M105"><mml:mo>(</mml:mo><mml:mfrac linethickness="0.0pt"><mml:mrow><mml:mo>|</mml:mo><mml:mi>V</mml:mi><mml:mo>|</mml:mo><mml:mo>&#x0002B;</mml:mo><mml:mn>1</mml:mn></mml:mrow><mml:mrow><mml:mn>2</mml:mn></mml:mrow></mml:mfrac><mml:mo>)</mml:mo></mml:math></inline-formula> and the number of subtrees for star graphs is <italic>O</italic>(2<sup>|<italic>V</italic>|</sup>) (<xref ref-type="bibr" rid="B64">Sz&#x000E9;kely and Wang, 2005</xref>). This leads to the complexity result that the number of subgraphs grows as <italic>O</italic>(|<italic>V</italic>|<sup>2</sup>) for chain graphs, which in turn yields a time complexity of <italic>O</italic>(|<italic>V</italic>|<sup>3</sup>) since |<italic>E</italic>| &#x0003D; |<italic>V</italic>| &#x02212; 1. For the star graphs, we have |<italic>E</italic>| &#x0003D; |<italic>V</italic>| &#x02212; 1 and thus obtain complexity <italic>O</italic>(|<italic>V</italic>| &#x000B7; 2<sup>|<italic>V</italic>|</sup>), which also aligns with the study by <xref ref-type="bibr" rid="B48">Ono and Lohman (1990)</xref>. Finally, we obtain that the number of connected subgraphs for a cycle graph with |<italic>V</italic>| is |<italic>V</italic>|(|<italic>V</italic>| &#x02212; 1) &#x0002B; 1, which leads to a time complexity <italic>O</italic>(|<italic>V</italic>|<sup>3</sup>), because |<italic>E</italic>| &#x0003D; |<italic>V</italic>|.</p>
<p>Since <xref ref-type="statement" rid="algo3">Algorithm 3</xref> is used to construct the terms for the HUBO optimization problem, the correspondence between the time complexity and the number of terms is one-to-one. Thus, the number of terms scales one-to-one with the time complexity. To summarize this complexity, in the worst case, term generation scales as <italic>O</italic>(2<sup>|<italic>V</italic>|</sup>), although practical query graphs often yield polynomial growth.</p>
</sec>
<sec>
<label>5.1.2</label>
<title>Variable scalability</title>
<p>Our method achieves advantageous variable scalability compared to the most scalable methods (<xref ref-type="bibr" rid="B57">Sch&#x000F6;nberger et al., 2023a</xref>,<xref ref-type="bibr" rid="B58">b</xref>). The model in the study by <xref ref-type="bibr" rid="B55">Saxena et al. (2024)</xref> uses the same variable definitions as that in the study by <xref ref-type="bibr" rid="B58">Sch&#x000F6;nberger et al. (2023b)</xref>, so the scalability comparison also applies to this article. The scalability is visualized in <xref ref-type="fig" rid="F4">Figure 4</xref> for cycle query graphs. The chain, star, and tree graphs have identical relative scalability between the three methods. We aim to emphasize that these are the only mandatory variables for the two compared methods. The previous techniques require more variables to estimate the cost thresholds, which depend on the problem. We excluded the variable scalability described by <xref ref-type="bibr" rid="B43">Nayak et al. (2024)</xref> since the growth of variable count is exponential in their study.</p>
<fig position="float" id="F4">
<label>Figure 4</label>
<caption><p>Comparison of the number of mandatory variables in the study by <xref ref-type="bibr" rid="B57">Sch&#x000F6;nberger et al. (2023a</xref>,<xref ref-type="bibr" rid="B58">b)</xref> to all variables in our optimization model.</p></caption>
<graphic mimetype="image" mime-subtype="tiff" xlink:href="fcomp-07-1649354-g0004.tif">
<alt-text content-type="machine-generated">Line graph showing the number of variables (in thousands) on the y-axis and the number of relations on the x-axis. Three lines represent different methods: Q-Join (purple), Sch&#x000F6;nberger et al. (2023) (red), and Sch&#x000F6;nberger et al. (2024) (cyan). Q-Join shows the lowest increase, Sch&#x000F6;nberger et al. (2024) is moderate, and Sch&#x000F6;nberger et al. (2023) shows the highest increase.</alt-text>
</graphic>
</fig>
</sec>
</sec>
</sec>
<sec id="s6">
<label>6</label>
<title>Experimental evaluation</title>
<p>In this section, we present the results of a comprehensive experimental evaluation that includes optimizing join order selection on various combinations of query graphs, problem formulations, and classical and quantum optimizers. For each method proposed in this article, we evaluate the technique against five common query graph types: clique, star, chain, cycle, and tree. Each query graph is labeled using the format &#x00027;Graph name - number of nodes&#x00027;. For each graph type and graph size, we sampled 20 query graph instances with random cardinalities and selectivities. The cardinalities are randomly sampled from the range 10 to 50, and selectivity from the interval (0, 1]. The costs are summed over the 20 query graph instances, describing a realistic cumulative error, and scaled with respect to the cost returned from the dynamic programming algorithm <italic>with</italic> cross products, which is the optimal left-deep plan. This means that the results are compared to the optimal left-deep plans. The code, the exact query graphs, and parameters used for this experimental evaluation are available in the GitHub repository (<xref ref-type="bibr" rid="B72">Uotila, 2025a</xref>). Since we have used 20 query graph instances for five different graph types, ranging in size from 3 to 60, and solved them with four different quantum and classical solvers, the total number of optimized problems is in the thousands. We refer to the implementation of our algorithms as Q-Join.</p>
<p>After fixing one of the three proposed methods and a query graph instance, we constructed the corresponding HUBO optimization problem. Then, we submitted the problem for each selected solver. The available solvers include two quantum computing approaches (D-Wave quantum annealer and D-Wave hybrid quantum annealer) and two classical approaches (exact poly solver and Gurobi optimizer). In all cases except the exact poly solver, the HUBO problem needs to be translated into the equivalent QUBO problem.</p>
<p>Our evaluation focuses on solution quality, rather than solver runtime. A direct comparison of execution times is impractical, as system-level latencies heavily influence them. A direct comparison of execution times might be misleading in this scenario because the quantum annealer&#x00027;s microsecond-scale annealing time is only one component of a larger process that includes significant classical overhead from problem embedding and post-processing. The pre- and post-processing latencies include problem encoding, network communication, solver queuing, and interpreting the result. We identify that a meaningful comparison of execution times between classical and quantum systems is still a research question.</p>
<p><bold>Summary of proposed methods</bold>. We have proposed three algorithms to solve the join order selection problem with a higher-order unconstrained binary optimization model. <xref ref-type="table" rid="T1">Table 1</xref> introduces names for these methods, which are used in this Experimental Evaluation section.</p>
<table-wrap position="float" id="T1">
<label>Table 1</label>
<caption><p>Summary of proposed algorithms.</p></caption>
<table frame="box" rules="all">
<thead>
<tr>
<th valign="top" align="left"><bold>Method name</bold></th>
<th valign="top" align="left"><bold>Cost function</bold></th>
<th valign="top" align="left"><bold>Validity constraint</bold></th>
</tr>
</thead>
<tbody>
<tr>
<td valign="top" align="left">Precise 1</td>
<td valign="top" align="left">Precise cost function</td>
<td valign="top" align="left">Cost function dependent</td>
</tr>
<tr>
<td valign="top" align="left">Precise 2</td>
<td valign="top" align="left">Precise cost function</td>
<td valign="top" align="left">Cost function independent</td>
</tr>
<tr>
<td valign="top" align="left">Heuristic</td>
<td valign="top" align="left">Heuristic cost function</td>
<td valign="top" align="left">Cost function dependent</td>
</tr></tbody>
</table>
</table-wrap>
<p>The results should be interpreted as follows. For each case, we have solved the join order selection problem using four different methods: our algorithm in evaluation, dynamic programming without cross products, a greedy algorithm without cross products, and finally, dynamic programming with cross products. Since dynamic programming with cross products produces the optimal left-deep plan, we scale the cumulative cost over 20 different join order optimization problems with this cost. This way, we obtain a metric that enables us to compare these methods without explicitly dealing with cost values. The actual range of costs is arbitrary since the cardinalities and selectivities are randomly sampled. For example, suppose our algorithm has a scaled cost of 1.007. In that case, this means that the cumulative cost of the 20 returned plans from our algorithm is 0.7% larger than the cumulative cost for the optimal plans from dynamic programming with cross products.</p>
<sec>
<label>6.1</label>
<title>Evaluating Precise 1 formulation</title>
<p>First, we evaluate Precise 1 formulation, which combines a precise cost function and cost-dependent validity constraints. <xref ref-type="fig" rid="F5">Figure 5</xref> shows the results of optimizing join order selection using D-Wave&#x00027;s exact poly solver, which is part of the Ocean framework. Following the bounds given by Theorem 3, the HUBO model consistently generates a plan that matches the quality of the plan produced by the dynamic programming algorithm without the cross products. We also observe that the returned plans are at most 0.7% larger than the optimal plan from dynamic programming with the cross products.</p>
<fig position="float" id="F5">
<label>Figure 5</label>
<caption><p>Precise 1 results using D-Wave&#x00027;s exact poly solver. For Clique-3, Cycle-3, Star-4, and Star-5, all three methods achieved optimal cost.</p></caption>
<graphic mimetype="image" mime-subtype="tiff" xlink:href="fcomp-07-1649354-g0005.tif">
<alt-text content-type="machine-generated">Nine bar charts compare scaled costs across three methods: Q-Join (blue), Dynamic Programming without cross-products (green), and Greedy without cross-products (orange). Each chart represents a different graph structure, including Clique-4, Cycle-4, Cycle-5, Star-3, Chain-3, Chain-4, Chain-5, Chain-6, Tree-3, Tree-4, Tree-5, and Tree-6.</alt-text>
</graphic>
</fig>
<p>Second, we solved the same HUBO formulations using the classical Gurobi solver. The results are presented in <xref ref-type="fig" rid="F6">Figure 6</xref>. The HUBO-to-QUBO translation does not decrease the algorithm&#x00027;s quality, and the method is able to find the correct plans. The results remain very close to the optimal join tree, consistently matching the quality of the dynamic programming algorithm that does not use cross products.</p>
<fig position="float" id="F6">
<label>Figure 6</label>
<caption><p>Precise 1 results using Gurobi solver.</p></caption>
<graphic mimetype="image" mime-subtype="tiff" xlink:href="fcomp-07-1649354-g0006.tif">
<alt-text content-type="machine-generated">Bar charts comparing scaled costs for various graph structures. Each panel, labeled from Clique-4 to Tree-6, displays cost comparisons among three methods: Q-Join: Precise 1 (blue), Dynamic programming without cross-products (green), and Greedy without cross-products (orange). The y-axis represents scaled cost values ranging slightly above one, with noticeable variations in heights across methods and graph types.</alt-text>
</graphic>
</fig>
<p>Third, we addressed the same problems using D-Wave&#x00027;s Leap Hybrid solver, a cloud-based quantum-classical optimization platform. The results are in <xref ref-type="fig" rid="F7">Figure 7</xref>. In this case, the results are consistently as good as those from the dynamic programming algorithm without the cross products, with some exceptions due to the heuristic nature of the quantum computer: Cycle-6, Chain-7, and Tree-6.</p>
<fig position="float" id="F7">
<label>Figure 7</label>
<caption><p>Precise 1 results using D-Wave&#x00027;s Leap Hybrid solver.</p></caption>
<graphic mimetype="image" mime-subtype="tiff" xlink:href="fcomp-07-1649354-g0007.tif">
<alt-text content-type="machine-generated">Bar chart grid comparing three algorithms: Q-Join: Presice 1 (blue), Dynamic programming without cross-products (green), and Greedy without cross-products (orange), across various graph types (Clique, Cycle, Star, Chain, Tree). The x-axis represents graph types, and the y-axis represents scaled cost. Each panel shows the costs for the different algorithms for the specified graph type. Results vary, showing differences in performance efficiency.</alt-text>
</graphic>
</fig>
<p>Finally, <xref ref-type="fig" rid="F8">Figure 8</xref> shows the results from D-Wave&#x00027;s quantum annealer, which does not use hybrid features to increase solution quality. This resulted in performance that did not match that of the previous solvers, and this performance decrease had already been identified in the study by <xref ref-type="bibr" rid="B57">Sch&#x000F6;nberger et al. (2023a)</xref>. While the quality was not as good as the previous solutions, the valid plans might still be usable, with only a few percent deviation from the global optimum.</p>
<fig position="float" id="F8">
<label>Figure 8</label>
<caption><p>Precise 1 results using D-Wave&#x00027;s quantum annealer without hybrid features.</p></caption>
<graphic mimetype="image" mime-subtype="tiff" xlink:href="fcomp-07-1649354-g0008.tif">
<alt-text content-type="machine-generated">Bar charts show the scaled costs of different algorithms for various graph types: Clique, Cycle, Star, Chain, and Tree. The algorithms compared are Q-Join: Precise 1 (blue), Dynamic programming without cross-products (green), and Greedy without cross-products (orange). Each graph type and size shows how these algorithms perform relative to each other, with Q-Join generally having higher costs in most cases.</alt-text>
</graphic>
</fig>
</sec>
<sec>
<label>6.2</label>
<title>Evaluating Precise 2 formulation</title>
<p>The key idea behind the Precise 2 formulation is to tackle larger join order optimization cases, as the validity constraints are more efficient in terms of the number of higher-order terms. We include the exact poly solver results to demonstrate that this formulation encodes precisely the correct plans. For the other solvers, we only show results that optimized larger queries compared to the previous Precise 1 method.</p>
<p>First, the results from the exact poly solver in <xref ref-type="fig" rid="F9">Figure 9</xref> demonstrate that this algorithm follows the bounds of Theorem 3. In practice, the returned plans are again very close to the optimal plans. We can also see that compared to the Precise 1 method, the different set of validity constraints work equally well.</p>
<fig position="float" id="F9">
<label>Figure 9</label>
<caption><p>Precise 2 results using D-Wave&#x00027;s exact poly solver.</p></caption>
<graphic mimetype="image" mime-subtype="tiff" xlink:href="fcomp-07-1649354-g0009.tif">
<alt-text content-type="machine-generated">Seven bar charts compare scaled costs for different graph structures: Cycle-4, Cycle-5, Star-3, Chain-3, Chain-4, Chain-5, Tree-3, Tree-4, and Tree-5. They show results for Q-Join: Presice 2 (purple), Dynamic programming without cross-products (turquoise), and Greedy without cross-products (yellow). Each chart displays minor variations across the methods.</alt-text>
</graphic>
</fig>
<p>Second, to evaluate the Gurobi solver, we scaled up the problem sizes significantly from the Precise 1 method. The results are presented in <xref ref-type="fig" rid="F10">Figure 10</xref>. On the other hand, we observed that finding the point that minimizes both cost and validity constraints becomes increasingly challenging as the problem sizes increase.</p>
<fig position="float" id="F10">
<label>Figure 10</label>
<caption><p>Precise 2 results that were not part of Precise 1 results using Gurobi solver.</p></caption>
<graphic mimetype="image" mime-subtype="tiff" xlink:href="fcomp-07-1649354-g0010.tif">
<alt-text content-type="machine-generated">Bar charts compare scaled costs for different algorithms: Q-Join: Presice 2 (purple), Dynamic programming without cross-products (blue), and Greedy without cross-products (green). Categories include Clique, Cycle, Star, Chain, and Tree, each showing varying cost efficiencies across the algorithms.</alt-text>
</graphic>
</fig>
<p>Slightly unexpectedly, the hybrid solver did not perform as well as we expected, as shown in <xref ref-type="fig" rid="F11">Figure 11</xref>. The solver does not have tunable hyperparameters, which could be adjusted to obtain better results. Finally, we do not include the results from the D-Wave quantum solver without hybrid features since the solver did not scale beyond the cases that were already presented in <xref ref-type="fig" rid="F8">Figure 8</xref>.</p>
<fig position="float" id="F11">
<label>Figure 11</label>
<caption><p>Precise 2 results using D-Wave&#x00027;s Leap Hybrid solver.</p></caption>
<graphic mimetype="image" mime-subtype="tiff" xlink:href="fcomp-07-1649354-g0011.tif">
<alt-text content-type="machine-generated">Bar charts compare the scaled costs of three methods: Q-Join (purple), dynamic programming without cross-products (cyan), and greedy without cross-products (yellow) across different graph structures. The graphs include Clique-5, Cycle-7, Cycle-8, Star-7, Star-8, Chain-8, Tree-10, Tree-7, Tree-8, and Tree-9. Each graph shows varying performance, with Q-Join consistently having higher costs, while the other two methods vary depending on the graph type.</alt-text>
</graphic>
</fig>
</sec>
<sec>
<label>6.3</label>
<title>Evaluating heuristic formulation</title>
<p>The key motivation behind the heuristic formulation is to tackle even larger query graphs. Our main goal is to demonstrate that this algorithm reaches acceptable results with superior scalability compared to the previous Precise 1 and 2 formulations. The results also indicate that Theorem 4 is respected in practice. The optimal results are now computed with dynamic programming <italic>without</italic> cross products. Due to space limitations, we only included the results from the Gurobi solver, which we consider the most demonstrative, and we had unlimited access to it since it runs locally.</p>
<p>The results are presented so that we have computed and scaled the difference between each pair of methods. A value that differs from 0 indicates that the two methods gave different join trees with different costs. Since one of the methods is near-optimal (DP without cross products), it is clear which method produced the suboptimal result. This way, we can compare all three methods simultaneously. In all cases, we observe that the heuristic algorithm respects Theorem 4 in practice, meaning that the formulation produced a plan with a cost equal to the classical greedy algorithm.</p>
<p><xref ref-type="fig" rid="F12">Figure 12</xref> shows the results of applying the heuristic method to chain, cycle, and clique query graphs. Scalability for clique graphs in this complex case is modest, and greedy plans are generally far from optimal plans for both our method and the classical greedy algorithm. The results for chain graphs and cycle graphs demonstrate the best scalability. For cycle graphs, our greedy method was able to find better plans than the classical greedy algorithm.</p>
<fig position="float" id="F12">
<label>Figure 12</label>
<caption><p>Heuristic results for different query graph topologies using Gurobi solver. Optimal results were solvable up to 16 relations. Considering the results for star and tree graphs, our algorithm and the greedy algorithm without cross products, we consistently obtained the same results.</p></caption>
<graphic mimetype="image" mime-subtype="tiff" xlink:href="fcomp-07-1649354-g0012.tif">
<alt-text content-type="machine-generated">Three line graphs display cost ratios versus the number of relations for different structures: Chain, Cycle, and Clique. Quantum/Greedy (blue) and Quantum/Optimal (orange) lines are plotted, with a red dashed line indicating the perfect ratio (1.0). Chain shows stability except for some Quantum/Optimal spikes. Cycle and Clique show more variation, with notable spikes in Quantum/Optimal.</alt-text>
</graphic>
</fig>
</sec>
<sec>
<label>6.4</label>
<title>Comparison with quantum-inspired digital annealing</title>
<p>We evaluated the method proposed in the study by <xref ref-type="bibr" rid="B58">Sch&#x000F6;nberger et al. (2023b)</xref> using the same workloads and present the results in <xref ref-type="fig" rid="F13">Figure 13</xref>. Their technique is the improved algorithm from the study by <xref ref-type="bibr" rid="B57">Sch&#x000F6;nberger et al. (2023a)</xref>. The results demonstrate that our methods perform at the same level as theirs on these workloads. The authors propose a novel readout technique that enhances the results. Since we could not access special quantum-inspired hardware, the digital annealer, we used the Gurobi solver, which returns only a single result by default. Thus, the readout technique was not applicable. In the studied cases, it did not seem to decrease quality.</p>
<fig position="float" id="F13">
<label>Figure 13</label>
<caption><p>QUBO formulation accuracy on different query graph topologies with QUBO formulation proposed in the study by <xref ref-type="bibr" rid="B58">Sch&#x000F6;nberger et al. (2023b)</xref>.</p></caption>
<graphic mimetype="image" mime-subtype="tiff" xlink:href="fcomp-07-1649354-g0013.tif">
<alt-text content-type="machine-generated">Five line graphs compare cost ratios for different structures: Clique, Cycle, Star, Chain, and Tree. Each graph plots the cost ratio against the number of relations. Values vary, with distinct trends for each structure type, showing fluctuations and patterns in cost effectiveness.</alt-text>
</graphic>
</fig>
<p>The results demonstrate that their method achieves a comparable accuracy to ours, which is optimal or nearly optimal. We have computed the exact results with dynamic programming using cross products and compared the relative cumulative costs between the methods. Their method also appears to be able to identify beneficial cross products. Due to the higher-order terms in our method, which currently need to be rewritten in quadratic format, their method remains more scalable than ours. On the other hand, our theoretical bounds, query-graph-aware problem formulation, the more straightforward variable definition, and the novel usage of the higher-order model demonstrate specific contributions and improvements over their methods. We are also confident that our model will incorporate features that enable expansion for outer joins, accommodate more complex dependencies between predicates, and allow the usage of other types of cost functions.</p>
</sec>
</sec>
<sec sec-type="discussion" id="s7">
<label>7</label>
<title>Discussion</title>
<p>In this study, we developed a novel higher-order binary optimization formulation for optimizing join order selection for left-deep query plans. This is a fundamentally new approach to one of the most studied query optimization problems in the database domain. Our formulation is accompanied by formal guarantees, as proven in Theorems 3 and 4. Our method respects query graphs, which makes it distinct from previous formulations. Although this leaves out cross products, it also simplifies problem formulation for certain query graphs. It paves the way for future methods that rely on information about query graphs. As shown in <xref ref-type="fig" rid="F4">Figure 4</xref>, our method requires a relatively small number of binary variables. Finally, we conducted a comprehensive experimental evaluation that demonstrated the usage of quantum annealers in this task, deepened our understanding of differences between quantum and classical solvers in this real-life problem, and showed that the results in Theorems 3 and 4 are respected in practice.</p>
<p>The starting point for our study has been primarily the previous quantum computing formulations (<xref ref-type="bibr" rid="B57">Sch&#x000F6;nberger et al., 2023a</xref>; <xref ref-type="bibr" rid="B81">Winker et al., 2023a</xref>; <xref ref-type="bibr" rid="B59">Sch&#x000F6;nberger et al., 2023c</xref>; <xref ref-type="bibr" rid="B43">Nayak et al., 2024</xref>; <xref ref-type="bibr" rid="B19">Franz et al., 2024</xref>; <xref ref-type="bibr" rid="B58">Sch&#x000F6;nberger et al., 2023b</xref>; <xref ref-type="bibr" rid="B55">Saxena et al., 2024</xref>) for the join order selection problem. Our method&#x00027;s scalability in real-life problems outperforms many previous studies (<xref ref-type="bibr" rid="B57">Sch&#x000F6;nberger et al., 2023a</xref>; <xref ref-type="bibr" rid="B19">Franz et al., 2024</xref>; <xref ref-type="bibr" rid="B59">Sch&#x000F6;nberger et al., 2023c</xref>), where the authors have demonstrated their algorithms with 2 to 7 relations. The method proposed in the study by <xref ref-type="bibr" rid="B58">Sch&#x000F6;nberger et al. (2023b)</xref> offers the best scalability and accuracy. However, their algorithm lacks a guarantee of optimality and requires the use of more variables (<xref ref-type="fig" rid="F4">Figure 4</xref>). The comparison to this approach showed accuracy similar to our method in small query graphs. We also note that classical solvers compete with the quantum annealers in this task, even though they run locally on a laptop. This demonstrates that quantum annealers are not scalable enough to solve these types of problems efficiently, and their performance is crucially problem-dependent.</p>
<p>Classical approaches for solving HUBO problems typically rely on approximate methods due to the exponential growth in complexity of these problems. Integer programming can be used to find approximate solutions for HUBO problems, but it suffers from scalability issues and does not always ensure feasibility (<xref ref-type="bibr" rid="B41">Munoz, 2017</xref>). Machine learning techniques, including graph neural networks, have been explored for approximating HUBO solutions (<xref ref-type="bibr" rid="B60">Schuetz et al., 2022</xref>). However, these approaches often require training data and may struggle to generalize to previously unseen instances. Simulated annealing has been applied as another classical strategy for tackling HUBO problems (<xref ref-type="bibr" rid="B78">Wang et al., 2025</xref>). While these classical methods are effective for small- and medium-sized instances, they encounter significant challenges as problem size increases, highlighting the potential usability of quantum-native approaches such as QAOA. In theory, the HUBO formulations in this article can be addressed using the same QAOA-based methods employed in <xref ref-type="bibr" rid="B74">Uotila et al. (2025)</xref>.</p>
<p>Quantum computing for HUBO problems represents an emerging area in the field of quantum optimization. For example, <xref ref-type="bibr" rid="B11">Campbell and Dahl (2022)</xref> explored the use of the Quantum Approximate Optimization Algorithm (QAOA) for higher-order graph coloring problems. Techniques such as bias-field digitized counterdiabatic quantum optimization have been developed to enhance the solution of higher-order binary problems (<xref ref-type="bibr" rid="B53">Romero et al., 2025</xref>; <xref ref-type="bibr" rid="B9">Cadavid et al., 2025</xref>), and various methods have been proposed for optimizing variational quantum circuits tailored to these challenges (<xref ref-type="bibr" rid="B76">Verchere et al., 2023</xref>). Higher-order problems have also served as benchmarks for comparing QAOA and quantum annealing performance (<xref ref-type="bibr" rid="B51">Pelofske et al., 2023</xref>; <xref ref-type="bibr" rid="B54">Sachdeva et al., 2024</xref>; <xref ref-type="bibr" rid="B52">Pelofske et al., 2024b</xref>; <xref ref-type="bibr" rid="B21">Gilbert et al., 2023</xref>), as well as for studying the scaling behavior and parameter concentration properties of QAOA (<xref ref-type="bibr" rid="B50">Pelofske et al., 2024a</xref>). Initial applications for HUBO formulations include higher-order portfolio optimization (<xref ref-type="bibr" rid="B74">Uotila et al., 2025</xref>), the formalization of practical matrix multiplication algorithm search (<xref ref-type="bibr" rid="B71">Uotila, 2024b</xref>), and optimization in railway rescheduling (<xref ref-type="bibr" rid="B14">Domino et al., 2022</xref>). While HUBO formulations are classically challenging, it remains open whether they offer an actual computational advantage on quantum hardware.</p>
<p>Multiple challenges remain. The biggest challenge in our method is the higher-order terms, whose number grows exponentially in some cases. The current HUBO problem formulations also do not account for bushy trees or cross products, which would further enhance the quality of the solution. We are also limited to inner joins and the simple cost model. The problem of optimizing join order selection also relies on cardinality estimations, which is a separate challenge in query optimization. Finally, there is considerable room for improvement in solving HUBO problems on both classical and quantum hardware. Very few methods can effectively tackle HUBO optimization problems. In this regard, quantum computing appears to be theoretically one of the most promising approaches to optimizing complex HUBOs. In future research, we are excited to explore the universal quantum computing capabilities for solving HUBOs. Unfortunately, the problem sizes studied in this work were still too large for the current universal quantum computers.</p>
<p>Previous methods have been limited to inner joins. Extending our binary variables to model non-inner joins is theoretically straightforward, for instance, by adding a component to indicate the join type (inner or outer). While this modification is simple, the cost function and constraints also need adjustments. Since our cost HUBO is explicitly based on the recursive join order cost function, encoding predicate dependencies is also feasible. Our HUBO formulations can be further approximated with other heuristics to make them feasible for solving a larger set of complex query graphs. Exploring these extensions offers promising directions for future research in join order optimization with quantum computing.</p>
</sec>
<sec sec-type="conclusions" id="s8">
<label>8</label>
<title>Conclusion</title>
<p>In this study, we have developed three novel graph-aware higher-order binary optimization models to solve the join order selection problem in relational databases. The HUBO problems can be divided into cost functions and validity constraints. We presented two new binary optimization formulations for the cost function and proved that one encodes the same join trees as the dynamic programming algorithm without cross products. The other finds plans that are at least as good as those returned by the greedy algorithm without cross products. Finally, we presented a comprehensive experimental evaluation of these algorithms on various quantum and classical solvers. The experimental evaluation demonstrated the practical usability of these HUBO formulations and the fact that we respect the proven bounds in practice. While classical solvers remained competitive, these types of binary optimization models will serve as the essential element for future quantum optimization platforms.</p>
</sec>
</body>
<back>
<sec sec-type="data-availability" id="s9">
<title>Data availability statement</title>
<p>The datasets presented in this study can be found in online repositories. The names of the repository/repositories and accession number(s) can be found in the article/supplementary material.</p>
</sec>
<sec sec-type="author-contributions" id="s10">
<title>Author contributions</title>
<p>VU: Writing &#x02013; original draft, Software, Writing &#x02013; review &#x00026; editing, Data curation, Conceptualization, Investigation, Formal analysis, Visualization, Methodology.</p>
</sec>
<sec sec-type="COI-statement" id="conf1">
<title>Conflict of interest</title>
<p>The author declares that the research was conducted in the absence of any commercial or financial relationships that could be construed as a potential conflict of interest.</p>
</sec>
<sec sec-type="ai-statement" id="s12">
<title>Generative AI statement</title>
<p>The author(s) declare that Gen AI was used in the creation of this manuscript. Generative AI was used to improve the quality of language, code and visualizations.</p>
<p>Any alternative text (alt text) provided alongside figures in this article has been generated by Frontiers with the support of artificial intelligence and reasonable efforts have been made to ensure accuracy, including review by the authors wherever possible. If you identify any issues, please contact us.</p></sec>
<sec sec-type="disclaimer" id="s13">
<title>Publisher&#x00027;s note</title>
<p>All claims expressed in this article are solely those of the authors and do not necessarily represent those of their affiliated organizations, or those of the publisher, the editors and the reviewers. Any product that may be evaluated in this article, or claim that may be made by its manufacturer, is not guaranteed or endorsed by the publisher.</p>
</sec>
<ref-list>
<title>References</title>
<ref id="B1">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Abbas</surname> <given-names>A.</given-names></name> <name><surname>Ambainis</surname> <given-names>A.</given-names></name> <name><surname>Augustino</surname> <given-names>B.</given-names></name> <name><surname>Baertschi</surname> <given-names>A.</given-names></name> <name><surname>Buhrman</surname> <given-names>H.</given-names></name> <name><surname>Coffrin</surname> <given-names>C. J.</given-names></name> <etal/></person-group>. (<year>2024</year>). <source>Quantum Optimization: Potential, Challenges, and the Path Forward</source>. <publisher-loc>Washington, DC</publisher-loc>: <publisher-name>US Department of Energy</publisher-name>.<pub-id pub-id-type="pmid">38544151</pub-id></mixed-citation></ref>
<ref id="B2">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Aharonov</surname> <given-names>D.</given-names></name> <name><surname>van Dam</surname> <given-names>W.</given-names></name> <name><surname>Kempe</surname> <given-names>J.</given-names></name> <name><surname>Landau</surname> <given-names>Z.</given-names></name> <name><surname>Lloyd</surname> <given-names>S.</given-names></name> <name><surname>Regev</surname> <given-names>O.</given-names></name> <etal/></person-group>. (<year>2004</year>). <article-title>Adiabatic quantum computation is equivalent to standard quantum computation</article-title>. <source>arXiv [preprint]</source>. arXiv:quant-ph/0405098v2. doi: <pub-id pub-id-type="doi">10.48550/arXiv.quant-ph/0405098v2</pub-id><pub-id pub-id-type="pmid">25554316</pub-id></mixed-citation></ref>
<ref id="B3">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Albash</surname> <given-names>T.</given-names></name> <name><surname>Lidar</surname> <given-names>D. A.</given-names></name></person-group> (<year>2018</year>). <article-title>Adiabatic quantum computation</article-title>. <source>Rev. Mod. Phys</source>. 90, 015002. doi: <pub-id pub-id-type="doi">10.1103/RevModPhys.90.015002</pub-id></mixed-citation>
</ref>
<ref id="B4">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Apolloni</surname> <given-names>B.</given-names></name> <name><surname>Carvalho</surname> <given-names>C.</given-names></name> <name><surname>de Falco</surname> <given-names>D.</given-names></name></person-group> (<year>1989</year>). <article-title>Quantum stochastic optimization</article-title>. <source>Stoch. Processes Appl</source>. <volume>33</volume>, <fpage>233</fpage>&#x02013;<lpage>244</lpage>. doi: <pub-id pub-id-type="doi">10.1016/0304-4149(89)90040-9</pub-id></mixed-citation>
</ref>
<ref id="B5">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Aramon</surname> <given-names>M.</given-names></name> <name><surname>Rosenberg</surname> <given-names>G.</given-names></name> <name><surname>Valiante</surname> <given-names>E.</given-names></name> <name><surname>Miyazawa</surname> <given-names>T.</given-names></name> <name><surname>Tamura</surname> <given-names>H.</given-names></name> <name><surname>Katzgraber</surname> <given-names>H. G.</given-names></name> <etal/></person-group>. (<year>2019</year>). <article-title>Physics-inspired optimization for quadratic unconstrained problems using a digital annealer</article-title>. <source>Front. Phys</source>. <volume>7</volume>:<fpage>48</fpage>. doi: <pub-id pub-id-type="doi">10.3389/fphy.2019.00048</pub-id></mixed-citation>
</ref>
<ref id="B6">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Arute</surname> <given-names>F.</given-names></name> <name><surname>Arya</surname> <given-names>K.</given-names></name> <name><surname>Babbush</surname> <given-names>R.</given-names></name> <name><surname>Bacon</surname> <given-names>D.</given-names></name> <name><surname>Bardin</surname> <given-names>J. C.</given-names></name> <name><surname>Barends</surname> <given-names>R.</given-names></name> <etal/></person-group>. (<year>2019</year>). <article-title>Quantum supremacy using a programmable superconducting processor</article-title>. <source>Nature</source> <volume>574</volume>, <fpage>505</fpage>&#x02013;<lpage>510</lpage>. doi: <pub-id pub-id-type="doi">10.1038/s41586-019-1666-5</pub-id><pub-id pub-id-type="pmid">31645734</pub-id></mixed-citation></ref>
<ref id="B7">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Bittner</surname> <given-names>T.</given-names></name> <name><surname>Groppe</surname> <given-names>S.</given-names></name></person-group> (<year>2020</year>). <article-title>&#x0201C;Avoiding blocking by scheduling transactions using quantum annealing,&#x0201D;</article-title> in <source>Proceedings of the 24th Symposium on International Database Engineering &#x00026; Applications, IDEAS &#x00027;20</source> (<publisher-loc>New York, NY</publisher-loc>: <publisher-name>Association for Computing Machinery</publisher-name>), <fpage>1</fpage>&#x02013;<lpage>10</lpage>. doi: <pub-id pub-id-type="doi">10.1145/3410566.3410593</pub-id></mixed-citation>
</ref>
<ref id="B8">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Boros</surname> <given-names>E.</given-names></name> <name><surname>Hammer</surname> <given-names>P. L.</given-names></name></person-group> (<year>2002</year>). <article-title>Pseudo-boolean optimization</article-title>. <source>Discrete Appl. Math</source>. <volume>123</volume>, <fpage>155</fpage>&#x02013;<lpage>225</lpage>. doi: <pub-id pub-id-type="doi">10.1016/S0166-218X(01)00341-9</pub-id></mixed-citation>
</ref>
<ref id="B9">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Cadavid</surname> <given-names>A. G.</given-names></name> <name><surname>Dalal</surname> <given-names>A.</given-names></name> <name><surname>Simen</surname> <given-names>A.</given-names></name> <name><surname>Solano</surname> <given-names>E.</given-names></name> <name><surname>Hegade</surname> <given-names>N. N.</given-names></name></person-group> (<year>2025</year>). <article-title>Bias-field digitized counterdiabatic quantum optimization</article-title>. <source>Phys. Rev. Res</source>. <volume>7</volume>:<fpage>L022010</fpage>. doi: <pub-id pub-id-type="doi">10.1103/PhysRevResearch.7.L022010</pub-id></mixed-citation>
</ref>
<ref id="B10">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>&#x000C7;alikyilmaz</surname> <given-names>U.</given-names></name> <name><surname>Groppe</surname> <given-names>S.</given-names></name> <name><surname>Groppe</surname> <given-names>J.</given-names></name> <name><surname>Winker</surname> <given-names>T.</given-names></name> <name><surname>Prestel</surname> <given-names>S.</given-names></name> <name><surname>Shagieva</surname> <given-names>F.</given-names></name> <etal/></person-group>. (<year>2023</year>). <article-title>Opportunities for quantum acceleration of databases: optimization of queries and transaction schedules</article-title>. <source>VLDB</source> <volume>16</volume>, <fpage>2344</fpage>&#x02013;<lpage>2353</lpage>. doi: <pub-id pub-id-type="doi">10.14778/3598581.3598603</pub-id></mixed-citation>
</ref>
<ref id="B11">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Campbell</surname> <given-names>C.</given-names></name> <name><surname>Dahl</surname> <given-names>E.</given-names></name></person-group> (<year>2022</year>). <article-title>&#x0201C;Qaoa of the highest order,&#x0201D;</article-title> in <source>2022 IEEE 19th International Conference on Software Architecture Companion (ICSA-C)</source> (<publisher-loc>Honolulu, HI</publisher-loc>: <publisher-name>IEEE</publisher-name>), <fpage>141</fpage>&#x02013;<lpage>146</lpage>. doi: <pub-id pub-id-type="doi">10.1109/ICSA-C54293.2022.00035</pub-id></mixed-citation>
</ref>
<ref id="B12">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Cluet</surname> <given-names>S.</given-names></name> <name><surname>Moerkotte</surname> <given-names>G.</given-names></name></person-group> (<year>1995</year>). <article-title>&#x0201C;On the complexity of generating optimal left-deep processing trees with cross products,&#x0201D;</article-title> in <source>Database Theory &#x02013; ICDT &#x00027;95</source>, eds. <person-group person-group-type="editor"><name><surname>Gottlob</surname> <given-names>G.</given-names></name> <name><surname>Vardi</surname> <given-names>M. Y.</given-names></name></person-group> (<publisher-loc>Berlin, Heidelberg</publisher-loc>: <publisher-name>Springer Berlin Heidelberg</publisher-name>), <fpage>54</fpage>&#x02013;<lpage>67</lpage>. doi: <pub-id pub-id-type="doi">10.1007/3-540-58907-4_6</pub-id><pub-id pub-id-type="pmid">17955980</pub-id></mixed-citation></ref>
<ref id="B13">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Denchev</surname> <given-names>V. S.</given-names></name> <name><surname>Boixo</surname> <given-names>S.</given-names></name> <name><surname>Isakov</surname> <given-names>S. V.</given-names></name> <name><surname>Ding</surname> <given-names>N.</given-names></name> <name><surname>Babbush</surname> <given-names>R.</given-names></name> <name><surname>Smelyanskiy</surname> <given-names>V.</given-names></name> <etal/></person-group>. (<year>2016</year>). <article-title>What is the computational value of finite-range tunneling?</article-title> <source>Phys. Rev. X</source> <volume>6</volume>:<fpage>031015</fpage>. doi: <pub-id pub-id-type="doi">10.1103/PhysRevX.6.031015</pub-id></mixed-citation>
</ref>
<ref id="B14">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Domino</surname> <given-names>K.</given-names></name> <name><surname>Kundu</surname> <given-names>A.</given-names></name> <name><surname>Salehi</surname> <given-names>&#x000D6;.</given-names></name> <name><surname>Krawiec</surname> <given-names>K.</given-names></name></person-group> (<year>2022</year>). <article-title>Quadratic and higher-order unconstrained binary optimization of railway rescheduling for quantum computing</article-title>. <source>Quantum Inf. Process</source>. <volume>21</volume>:<fpage>337</fpage>. doi: <pub-id pub-id-type="doi">10.1007/s11128-022-03670-y</pub-id></mixed-citation>
</ref>
<ref id="B15">
<mixed-citation publication-type="web"><person-group person-group-type="author"><collab>D-Wave Quantum Inc</collab></person-group>. (<year>2024</year>). <source>Non-Quadratic (Higher-Degree) Polynomials</source>. Available online at: <ext-link ext-link-type="uri" xlink:href="https://docs.dwavequantum.com/en/latest/quantum_research/reformulating.html&#x00023;non-quadratic-higher-degree-polynomials">https://docs.dwavequantum.com/en/latest/quantum_research/reformulating.html&#x00023;non-quadratic-higher-degree-polynomials</ext-link> (Accessed February 01, 2024).</mixed-citation>
</ref>
<ref id="B16">
<mixed-citation publication-type="web"><person-group person-group-type="author"><collab>D-Wave Quantum Inc</collab></person-group>. (<year>2025</year>). <source>What is Quantum Annealing</source>? Available online at: <ext-link ext-link-type="uri" xlink:href="https://docs.dwavequantum.com/en/latest/quantum_research/quantum_annealing_intro.html">https://docs.dwavequantum.com/en/latest/quantum_research/quantum_annealing_intro.html</ext-link> (Accessed June 16, 2025).</mixed-citation>
</ref>
<ref id="B17">
<mixed-citation publication-type="web"><person-group person-group-type="author"><collab>D-Wave Systems Inc</collab></person-group>. (<year>2024</year>). <source>Dimod.Generators.Combinations</source>. Available online at: <ext-link ext-link-type="uri" xlink:href="https://docs.ocean.dwavesys.com/en/stable/docs_dimod/reference/generated/dimod.generators.combinations.html">https://docs.ocean.dwavesys.com/en/stable/docs_dimod/reference/generated/dimod.generators.combinations.html</ext-link> (Accessed: October 12, 2024).</mixed-citation>
</ref>
<ref id="B18">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Farhi</surname> <given-names>E.</given-names></name> <name><surname>Goldstone</surname> <given-names>J.</given-names></name> <name><surname>Gutmann</surname> <given-names>S.</given-names></name> <name><surname>Sipser</surname> <given-names>M.</given-names></name></person-group> (<year>2000</year>). <article-title>Quantum computation by adiabatic evolution</article-title>. <source>arXiv [preprint]</source>. arXiv:quant-ph/0001106. doi: <pub-id pub-id-type="doi">10.48550/arXiv.quant-ph/0001106</pub-id></mixed-citation>
</ref>
<ref id="B19">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Franz</surname> <given-names>M.</given-names></name> <name><surname>Winker</surname> <given-names>T.</given-names></name> <name><surname>Groppe</surname> <given-names>S.</given-names></name> <name><surname>Mauerer</surname> <given-names>W.</given-names></name></person-group> (<year>2024</year>). <article-title>Hype or heuristic? quantum reinforcement learning for join order optimisation</article-title>. <source>arXiv [preprint]</source>. arXiv:2405.07770. doi: <pub-id pub-id-type="doi">10.48550/arXiv.2405.07770</pub-id></mixed-citation>
</ref>
<ref id="B20">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Fritsch</surname> <given-names>K.</given-names></name> <name><surname>Scherzinger</surname> <given-names>S.</given-names></name></person-group> (<year>2023</year>). <article-title>Solving hard variants of database schema matching on quantum computers</article-title>. <source>Proc. VLDB Endowment</source> <volume>16</volume>, <fpage>3990</fpage>&#x02013;<lpage>3993</lpage>. doi: <pub-id pub-id-type="doi">10.14778/3611540.3611603</pub-id></mixed-citation>
</ref>
<ref id="B21">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Gilbert</surname> <given-names>V.</given-names></name> <name><surname>Rodriguez</surname> <given-names>J.</given-names></name> <name><surname>Louise</surname> <given-names>S.</given-names></name> <name><surname>Sirdey</surname> <given-names>R.</given-names></name></person-group> (<year>2023</year>). <article-title>&#x0201C;Solving higher order binary optimization problems on nisq devices: experiments and limitations,&#x0201D;</article-title> in <source>Lecture Notes in Computer Science, volume LNCS-10477 of Computational Science &#x02013; ICCS 2023, page 224&#x02013;232, Prague, Czech Republic</source>, eds. <person-group person-group-type="editor"><name><surname>Miky&#x00161;ka</surname> <given-names>J.</given-names></name> <name><surname>Mulatier</surname> <given-names>C. D.</given-names></name> <name><surname>Paszynski</surname> <given-names>M.</given-names></name> <name><surname>Krzhizhanovskaya</surname> <given-names>V. V.</given-names></name> <name><surname>Dongarra</surname> <given-names>J. J.</given-names></name> <name><surname>Sloot</surname> <given-names>P. M. A.</given-names></name></person-group> (<publisher-loc>Cham</publisher-loc>: <publisher-name>Springer Nature Switzerland</publisher-name>). doi: <pub-id pub-id-type="doi">10.1007/978-3-031-36030-5_18</pub-id></mixed-citation>
</ref>
<ref id="B22">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Gill</surname> <given-names>S. S.</given-names></name> <name><surname>Kumar</surname> <given-names>A.</given-names></name> <name><surname>Singh</surname> <given-names>H.</given-names></name> <name><surname>Singh</surname> <given-names>M.</given-names></name> <name><surname>Kaur</surname> <given-names>K.</given-names></name> <name><surname>Usman</surname> <given-names>M.</given-names></name> <etal/></person-group>. (<year>2022</year>). <article-title>Quantum computing: A taxonomy, systematic review and future directions</article-title>. <source>Softw. Pract. Exp</source>. <volume>52</volume>, <fpage>66</fpage>&#x02013;<lpage>114</lpage>. doi: <pub-id pub-id-type="doi">10.1002/spe.3039</pub-id><pub-id pub-id-type="pmid">39703783</pub-id></mixed-citation></ref>
<ref id="B23">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Grimm</surname> <given-names>R.</given-names></name> <name><surname>Weidem&#x000FC;ller</surname> <given-names>M.</given-names></name> <name><surname>Ovchinnikov</surname> <given-names>Y. B.</given-names></name></person-group> (<year>2000</year>). <article-title>&#x0201C;Optical dipole traps for neutral atoms,&#x0201D;</article-title> in <source>Advances In Atomic, Molecular, and Optical Physics, Vol. 42</source> (<publisher-loc>New York, NY</publisher-loc>: <publisher-name>Academic Press</publisher-name>), <fpage>95</fpage>&#x02013;<lpage>170</lpage>. doi: <pub-id pub-id-type="doi">10.1016/S1049-250X(08)60186-X</pub-id></mixed-citation>
</ref>
<ref id="B24">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Grover</surname> <given-names>L. K.</given-names></name></person-group> (<year>1996</year>). <article-title>&#x0201C;A fast quantum mechanical algorithm for database search,&#x0201D;</article-title> in <source>Proceedings of the Twenty-Eighth Annual ACM Symposium on Theory of Computing, STOC &#x00027;96</source> (<publisher-loc>New York, NY</publisher-loc>: <publisher-name>Association for Computing Machinery</publisher-name>), <fpage>212</fpage>&#x02013;<lpage>219</lpage>. doi: <pub-id pub-id-type="doi">10.1145/237814.237866</pub-id></mixed-citation>
</ref>
<ref id="B25">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Gruenwald</surname> <given-names>L.</given-names></name> <name><surname>Winker</surname> <given-names>T.</given-names></name> <name><surname>&#x000C7;alikyilmaz</surname> <given-names>U.</given-names></name> <name><surname>Groppe</surname> <given-names>J.</given-names></name> <name><surname>Groppe</surname> <given-names>S.</given-names></name></person-group> (<year>2023</year>). <article-title>&#x0201C;Index tuning with machine learning on quantum computers for large-scale database applications,&#x0201D;</article-title> in <source>Joint Workshops at 49th International Conference on Very Large Data Bases (VLDBW&#x00027;23) &#x02014; International Workshop on Quantum Data Science and Management (QDSM&#x00027;23)</source> (<publisher-loc>Vancouver, BC</publisher-loc>).</mixed-citation>
</ref>
<ref id="B26">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Harrow</surname> <given-names>A.</given-names></name> <name><surname>Montanaro</surname> <given-names>A.</given-names></name></person-group> (<year>2017</year>). <article-title>Quantum computational supremacy</article-title>. <source>Nature</source> <volume>549</volume>, <fpage>203</fpage>&#x02013;<lpage>209</lpage>. doi: <pub-id pub-id-type="doi">10.1038/nature23458</pub-id><pub-id pub-id-type="pmid">28905912</pub-id></mixed-citation></ref>
<ref id="B27">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Ibaraki</surname> <given-names>T.</given-names></name> <name><surname>Kameda</surname> <given-names>T.</given-names></name></person-group> (<year>1984</year>). <article-title>On the optimal nesting order for computing n-relational joins</article-title>. <source>ACM Trans. Database Syst</source>. <volume>9</volume>, <fpage>482</fpage>&#x02013;<lpage>502</lpage>. doi: <pub-id pub-id-type="doi">10.1145/1270.1498</pub-id></mixed-citation>
</ref>
<ref id="B28">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Kadowaki</surname> <given-names>T.</given-names></name> <name><surname>Nishimori</surname> <given-names>H.</given-names></name></person-group> (<year>1998</year>). <article-title>Quantum annealing in the transverse ising model</article-title>. <source>Phys. Rev. E</source> <volume>58</volume>, <fpage>5355</fpage>&#x02013;<lpage>5363</lpage>. doi: <pub-id pub-id-type="doi">10.1103/PhysRevE.58.5355</pub-id></mixed-citation>
</ref>
<ref id="B29">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Kim</surname> <given-names>Y.</given-names></name> <name><surname>Eddins</surname> <given-names>A.</given-names></name> <name><surname>Anand</surname> <given-names>S.</given-names></name> <name><surname>Wei</surname> <given-names>K. X.</given-names></name> <name><surname>van den Berg</surname> <given-names>E.</given-names></name> <name><surname>Rosenblatt</surname> <given-names>S.</given-names></name> <etal/></person-group>. (<year>2023</year>). <article-title>Evidence for the utility of quantum computing before fault tolerance</article-title>. <source>Nature</source> <volume>618</volume>, <fpage>500</fpage>&#x02013;<lpage>505</lpage>. doi: <pub-id pub-id-type="doi">10.1038/s41586-023-06096-3</pub-id><pub-id pub-id-type="pmid">37316724</pub-id></mixed-citation></ref>
<ref id="B30">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>King</surname> <given-names>A. D.</given-names></name> <name><surname>Nocera</surname> <given-names>A.</given-names></name> <name><surname>Rams</surname> <given-names>M. M.</given-names></name> <name><surname>Dziarmaga</surname> <given-names>J.</given-names></name> <name><surname>Wiersema</surname> <given-names>R.</given-names></name> <name><surname>Bernoudy</surname> <given-names>W.</given-names></name> <etal/></person-group>. (<year>2024</year>). <article-title>Computational supremacy in quantum simulation</article-title>. <source>arXiv [preprint]</source>. arXiv:2403.00910 [cond-mat, physics:quant-ph]. doi: <pub-id pub-id-type="doi">10.48550/arXiv.2403.00910</pub-id></mixed-citation>
</ref>
<ref id="B31">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Kirkpatrick</surname> <given-names>S.</given-names></name> <name><surname>Gelatt</surname> <given-names>C. D.</given-names></name> <name><surname>Vecchi</surname> <given-names>M. P.</given-names></name></person-group> (<year>1983</year>). <article-title>Optimization by simulated annealing</article-title>. <source>Science</source> <volume>220</volume>, <fpage>671</fpage>&#x02013;<lpage>680</lpage>. doi: <pub-id pub-id-type="doi">10.1126/science.220.4598.671</pub-id><pub-id pub-id-type="pmid">17813860</pub-id></mixed-citation></ref>
<ref id="B32">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Kittelmann</surname> <given-names>F.</given-names></name> <name><surname>Sulimov</surname> <given-names>P.</given-names></name> <name><surname>Stockinger</surname> <given-names>K.</given-names></name></person-group> (<year>2024</year>). <article-title>&#x0201C;Qardest: using quantum machine learning for cardinality estimation of join queries,&#x0201D;</article-title> in <source>Workshop on Quantum Computing and Quantum-Inspired Technology for Data-Intensive Systems and Applications, Q-Data 2024, Santiago, Chile, June 9-15, 2024</source> (<publisher-loc>New York, NY</publisher-loc>: <publisher-name>ACM</publisher-name>), I. Sabek, I. Trummer, and S. Prestel doi: <pub-id pub-id-type="doi">10.1145/3665225.3665444</pub-id></mixed-citation>
</ref>
<ref id="B33">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Knill</surname> <given-names>E.</given-names></name> <name><surname>Laflamme</surname> <given-names>R.</given-names></name> <name><surname>Milburn</surname> <given-names>G. J.</given-names></name></person-group> (<year>2001</year>). <article-title>A scheme for efficient quantum computation with linear optics</article-title>. <source>Nature</source> <volume>409</volume>, <fpage>46</fpage>&#x02013;<lpage>52</lpage>. doi: <pub-id pub-id-type="doi">10.1038/35051009</pub-id><pub-id pub-id-type="pmid">11343107</pub-id></mixed-citation></ref>
<ref id="B34">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Leis</surname> <given-names>V.</given-names></name> <name><surname>Gubichev</surname> <given-names>A.</given-names></name> <name><surname>Mirchev</surname> <given-names>A.</given-names></name> <name><surname>Boncz</surname> <given-names>P.</given-names></name> <name><surname>Kemper</surname> <given-names>A.</given-names></name> <name><surname>Neumann</surname> <given-names>T.</given-names></name> <etal/></person-group>. (<year>2015</year>). <article-title>How good are query optimizers, really?</article-title> <source>Proc. VLDB Endow</source>. <volume>9</volume>, <fpage>204</fpage>&#x02013;<lpage>215</lpage>. doi: <pub-id pub-id-type="doi">10.14778/2850583.2850594</pub-id></mixed-citation>
</ref>
<ref id="B35">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Liu</surname> <given-names>H.</given-names></name> <name><surname>Kumar</surname> <given-names>A.</given-names></name> <name><surname>Spedalieri</surname> <given-names>F.</given-names></name> <name><surname>Sabek</surname> <given-names>I.</given-names></name></person-group> (<year>2025</year>). <article-title>&#x0201C;Hybrid quantum-classical optimization for bushy join trees,&#x0201D;</article-title> in <source>Proceedings of the 2nd Workshop on Quantum Computing and Quantum-Inspired Technology for Data-Intensive Systems and Applications, Q-Data &#x00027;25</source> (<publisher-loc>New York, NY</publisher-loc>: <publisher-name>Association for Computing Machinery</publisher-name>), <fpage>20</fpage>&#x02013;<lpage>24</lpage>. doi: <pub-id pub-id-type="doi">10.1145/3736393.3736695</pub-id></mixed-citation>
</ref>
<ref id="B36">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Lucas</surname> <given-names>A.</given-names></name></person-group> (<year>2014</year>). <article-title>Ising formulations of many np problems</article-title>. <source>Front. Phys</source>. <volume>2</volume>:<fpage>5</fpage>. doi: <pub-id pub-id-type="doi">10.3389/fphy.2014.00005</pub-id></mixed-citation>
</ref>
<ref id="B37">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Madsen</surname> <given-names>L. S.</given-names></name> <name><surname>Laudenbach</surname> <given-names>F.</given-names></name> <name><surname>Askarani</surname> <given-names>M. F.</given-names></name> <name><surname>Rortais</surname> <given-names>F.</given-names></name> <name><surname>Vincent</surname> <given-names>T.</given-names></name> <name><surname>Bulmer</surname> <given-names>J. F. F.</given-names></name> <etal/></person-group>. (<year>2022</year>). <article-title>Quantum computational advantage with a programmable photonic processor</article-title>. <source>Nature</source> <volume>606</volume>, <fpage>75</fpage>&#x02013;<lpage>81</lpage>. doi: <pub-id pub-id-type="doi">10.1038/s41586-022-04725-x</pub-id><pub-id pub-id-type="pmid">35650354</pub-id></mixed-citation></ref>
<ref id="B38">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Mc Keever</surname> <given-names>C.</given-names></name> <name><surname>Lubasch</surname> <given-names>M.</given-names></name></person-group> (<year>2024</year>). <article-title>Towards adiabatic quantum computing using compressed quantum circuits</article-title>. <source>PRX Quantum</source> <volume>5</volume>:<fpage>020362</fpage>. doi: <pub-id pub-id-type="doi">10.1103/PRXQuantum.5.020362</pub-id></mixed-citation>
</ref>
<ref id="B39">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Moerkotte</surname> <given-names>G.</given-names></name> <name><surname>Neumann</surname> <given-names>T.</given-names></name></person-group> (<year>2006</year>). <article-title>&#x0201C;Analysis of two existing and one new dynamic programming algorithm for the generation of optimal bushy join trees without cross products,&#x0201D;</article-title> in <source>Proceedings of the 32nd International Conference on Very Large Data Bases, VLDB &#x00027;06</source> (<publisher-loc>Seoul</publisher-loc>: <publisher-name>VLDB Endowment</publisher-name>), <fpage>930</fpage>&#x02013;<lpage>941</lpage>.</mixed-citation>
</ref>
<ref id="B40">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Moerkotte</surname> <given-names>G.</given-names></name> <name><surname>Neumann</surname> <given-names>T.</given-names></name></person-group> (<year>2008</year>). <article-title>&#x0201C;Dynamic programming strikes back,&#x0201D;</article-title> in <source>Proceedings of the 2008 ACM SIGMOD International Conference on Management of Data</source> (<publisher-loc>Vancouver, BC</publisher-loc>: <publisher-name>ACM</publisher-name>), <fpage>539</fpage>&#x02013;<lpage>552</lpage>. doi: <pub-id pub-id-type="doi">10.1145/1376616.1376672</pub-id></mixed-citation>
</ref>
<ref id="B41">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Munoz</surname> <given-names>G.</given-names></name></person-group> (<year>2017</year>). <source>Integer Programming Techniques for Polynomial Optimization</source>. <publisher-loc>New York, NY</publisher-loc>: <publisher-name>Columbia University</publisher-name>.</mixed-citation>
</ref>
<ref id="B42">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Nayak</surname> <given-names>N.</given-names></name> <name><surname>Prisacaru</surname> <given-names>A.</given-names></name> <name><surname>&#x000C7;al&#x00131;ky&#x00131;lmaz</surname> <given-names>U.</given-names></name> <name><surname>Groppe</surname> <given-names>J.</given-names></name> <name><surname>Groppe</surname> <given-names>S.</given-names></name></person-group> (<year>2025</year>). <article-title>&#x0201C;Quantum-enhanced transaction scheduling with reduced complexity via solving qubo iteratively using a locking mechanism,&#x0201D;</article-title> in <source>Proceedings of the 2nd Workshop on Quantum Computing and Quantum-Inspired Technology for Data-Intensive Systems and Applications, Q-Data &#x00027;25</source> (<publisher-loc>New York, NY</publisher-loc>: <publisher-name>Association for Computing Machinery</publisher-name>), <fpage>26</fpage>&#x02013;<lpage>35</lpage>. doi: <pub-id pub-id-type="doi">10.1145/3736393.3736701</pub-id></mixed-citation>
</ref>
<ref id="B43">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Nayak</surname> <given-names>N.</given-names></name> <name><surname>Winker</surname> <given-names>T.</given-names></name> <name><surname>&#x000C7;alikyilmaz</surname> <given-names>U.</given-names></name> <name><surname>Groppe</surname> <given-names>S.</given-names></name> <name><surname>Groppe</surname> <given-names>J.</given-names></name></person-group> (<year>2024</year>). <article-title>Quantum join ordering by splitting the search space of qubo problems</article-title>. <source>Datenbank-Spektrum</source> <volume>24</volume>, <fpage>21</fpage>&#x02013;<lpage>32</lpage>. doi: <pub-id pub-id-type="doi">10.1007/s13222-024-00468-3</pub-id></mixed-citation>
</ref>
<ref id="B44">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Neumann</surname> <given-names>P.</given-names></name> <name><surname>Mizuochi</surname> <given-names>N.</given-names></name> <name><surname>Rempp</surname> <given-names>F.</given-names></name> <name><surname>Hemmer</surname> <given-names>P.</given-names></name> <name><surname>Watanabe</surname> <given-names>H.</given-names></name> <name><surname>Yamasaki</surname> <given-names>S.</given-names></name> <etal/></person-group>. (<year>2008</year>). <article-title>Multipartite entanglement among single spins in diamond</article-title>. <source>Science</source> <volume>320</volume>, <fpage>1326</fpage>&#x02013;<lpage>1329</lpage>. doi: <pub-id pub-id-type="doi">10.1126/science.1157233</pub-id><pub-id pub-id-type="pmid">18535240</pub-id></mixed-citation></ref>
<ref id="B45">
<mixed-citation publication-type="web"><person-group person-group-type="author"><name><surname>Neumann</surname> <given-names>T.</given-names></name> <name><surname>Gubichev</surname> <given-names>A.</given-names></name></person-group> (<year>2014</year>). <source>Query Optimization. Technische Universit&#x000E4;t M&#x000FC;nchen; Chair for Database Systems</source>. Available online at: <ext-link ext-link-type="uri" xlink:href="https://db.in.tum.de/teaching/ws1415/queryopt/?lang=en">https://db.in.tum.de/teaching/ws1415/queryopt/?lang=en</ext-link> (Accessed September 23, 2025).</mixed-citation>
</ref>
<ref id="B46">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Neumann</surname> <given-names>T.</given-names></name> <name><surname>Radke</surname> <given-names>B.</given-names></name></person-group> (<year>2018</year>). <article-title>&#x0201C;Adaptive optimization of very large join queries,&#x0201D;</article-title> in <source>Proceedings of the 2018 International Conference on Management of Data, SIGMOD &#x00027;18</source> (<publisher-loc>New York, NY</publisher-loc>: <publisher-name>Association for Computing Machinery</publisher-name>), <fpage>677</fpage>&#x02013;<lpage>692</lpage>. doi: <pub-id pub-id-type="doi">10.1145/3183713.3183733</pub-id></mixed-citation>
</ref>
<ref id="B47">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Nielsen</surname> <given-names>M. A.</given-names></name> <name><surname>Chuang</surname> <given-names>I. L.</given-names></name></person-group> (<year>2010</year>). <source>Quantum Computation and Quantum Information: 10th Anniversary Edition</source>. <publisher-loc>Cambridge</publisher-loc>: <publisher-name>Cambridge University Press</publisher-name>.</mixed-citation>
</ref>
<ref id="B48">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Ono</surname> <given-names>K.</given-names></name> <name><surname>Lohman</surname> <given-names>G. M.</given-names></name></person-group> (<year>1990</year>). <article-title>&#x0201C;Measuring the complexity of join enumeration in query optimization,&#x0201D;</article-title> in <source>Proceedings of the 16th International Conference on Very Large Data Bases, VLDB &#x00027;90</source> (<publisher-loc>San Francisco, CA</publisher-loc>: <publisher-name>Morgan Kaufmann Publishers Inc</publisher-name>), <fpage>314</fpage>&#x02013;<lpage>325</lpage>.</mixed-citation>
</ref>
<ref id="B49">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Paul</surname> <given-names>W.</given-names></name></person-group> (<year>1990</year>). <article-title>Electromagnetic traps for charged and neutral particles</article-title>. <source>Rev. Mod. Phys</source>. <volume>62</volume>:<fpage>531</fpage>. doi: <pub-id pub-id-type="doi">10.1103/RevModPhys.62.531</pub-id></mixed-citation>
</ref>
<ref id="B50">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Pelofske</surname> <given-names>E.</given-names></name> <name><surname>B&#x000E4;rtschi</surname> <given-names>A.</given-names></name> <name><surname>Cincio</surname> <given-names>L.</given-names></name> <name><surname>Golden</surname> <given-names>J.</given-names></name> <name><surname>Eidenbenz</surname> <given-names>S.</given-names></name></person-group> (<year>2024a</year>). <article-title>Scaling whole-chip qaoa for higher-order ising spin glass models on heavy-hex graphs</article-title>. <source>NPJ Quantum Inf</source>. <volume>10</volume>, <fpage>1</fpage>&#x02013;<lpage>18</lpage>. doi: <pub-id pub-id-type="doi">10.1038/s41534-024-00906-w</pub-id></mixed-citation>
</ref>
<ref id="B51">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Pelofske</surname> <given-names>E.</given-names></name> <name><surname>B&#x000E4;rtschi</surname> <given-names>A.</given-names></name> <name><surname>Eidenbenz</surname> <given-names>S.</given-names></name></person-group> (<year>2023</year>). <article-title>&#x0201C;Quantum annealing vs. qaoa: 127 qubit higher-order ising problems on NISQ computers,&#x0201D;</article-title> in <source>High Performance Computing: 38th International Conference, ISC High Performance 2023, Hamburg, Germany, May 21&#x02013;25, 2023, Proceedings</source> (<publisher-loc>Berlin, Heidelberg</publisher-loc>: <publisher-name>Springer-Verlag</publisher-name>), <fpage>240</fpage>&#x02013;<lpage>258</lpage>. doi: <pub-id pub-id-type="doi">10.1007/978-3-031-32041-5_13</pub-id></mixed-citation>
</ref>
<ref id="B52">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Pelofske</surname> <given-names>E.</given-names></name> <name><surname>B&#x000E4;rtschi</surname> <given-names>A.</given-names></name> <name><surname>Eidenbenz</surname> <given-names>S.</given-names></name></person-group> (<year>2024b</year>). <article-title>Short-depth qaoa circuits and quantum annealing on higher-order ising models</article-title>. <source>npj Quantum Inf</source>. <volume>10</volume>, <fpage>1</fpage>&#x02013;<lpage>19</lpage>. doi: <pub-id pub-id-type="doi">10.1038/s41534-024-00825-w</pub-id></mixed-citation>
</ref>
<ref id="B53">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Romero</surname> <given-names>S. V.</given-names></name> <name><surname>Visuri</surname> <given-names>A.-M.</given-names></name> <name><surname>Cadavid</surname> <given-names>A. G.</given-names></name> <name><surname>Simen</surname> <given-names>A.</given-names></name> <name><surname>Solano</surname> <given-names>E.</given-names></name> <name><surname>Hegade</surname> <given-names>N. N.</given-names></name> <etal/></person-group>. (<year>2025</year>). <article-title>Bias-field digitized counterdiabatic quantum algorithm for higher-order binary optimization</article-title>. <source>Commun. Phys</source>. <volume>8</volume>:<fpage>348</fpage>. doi: <pub-id pub-id-type="doi">10.1038/s42005-025-02270-3</pub-id></mixed-citation>
</ref>
<ref id="B54">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Sachdeva</surname> <given-names>N.</given-names></name> <name><surname>Hartnett</surname> <given-names>G. S.</given-names></name> <name><surname>Maity</surname> <given-names>S.</given-names></name> <name><surname>Marsh</surname> <given-names>S.</given-names></name> <name><surname>Wang</surname> <given-names>Y.</given-names></name> <name><surname>Winick</surname> <given-names>A.</given-names></name> <etal/></person-group>. (<year>2024</year>). <article-title>Quantum optimization using a 127-qubit gate-model ibm quantum computer can outperform quantum annealers for nontrivial binary optimization problems</article-title>. <source>arXiv [preprint]</source>. arXiv:2406.01743. doi: <pub-id pub-id-type="doi">10.48550/arXiv.2406.01743</pub-id></mixed-citation>
</ref>
<ref id="B55">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Saxena</surname> <given-names>P.</given-names></name> <name><surname>Sabek</surname> <given-names>I.</given-names></name> <name><surname>Spedalieri</surname> <given-names>F. M.</given-names></name></person-group> (<year>2024</year>). <article-title>&#x0201C;Constrained quadratic model for optimizing join orders,&#x0201D;</article-title> in <source>Workshop on Quantum Computing and Quantum-Inspired Technology for Data-Intensive Systems and Applications, Q-Data 2024, Santiago, Chile, June 9-15, 2024</source>, eds. <person-group person-group-type="editor"><name><surname>Sabek</surname> <given-names>I.</given-names></name> <name><surname>Trummer</surname> <given-names>I.</given-names></name> <name><surname>Prestel</surname> <given-names>S.</given-names></name></person-group> (<publisher-loc>New York, NT</publisher-loc>: <publisher-name>ACM</publisher-name>). doi: <pub-id pub-id-type="doi">10.1145/3665225.3665447</pub-id></mixed-citation>
</ref>
<ref id="B56">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Sch&#x000F6;nberger</surname> <given-names>M.</given-names></name></person-group> (<year>2022</year>). <article-title>&#x0201C;Applicability of quantum computing on database query optimization,&#x0201D;</article-title> in <source>Proceedings of the 2022 International Conference on Management of Data</source> (<publisher-loc>Philadelphia, PA</publisher-loc>: <publisher-name>ACM</publisher-name>), <fpage>2512</fpage>&#x02013;<lpage>2514</lpage>. doi: <pub-id pub-id-type="doi">10.1145/3514221.3520257</pub-id><pub-id pub-id-type="pmid">35179941</pub-id></mixed-citation></ref>
<ref id="B57">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Sch&#x000F6;nberger</surname> <given-names>M.</given-names></name> <name><surname>Scherzinger</surname> <given-names>S.</given-names></name> <name><surname>Mauerer</surname> <given-names>W.</given-names></name></person-group> (<year>2023a</year>). <article-title>&#x0201C;Ready to leap (by co-design)? join order optimisation on quantum hardware,&#x0201D;</article-title> in <source>Proceedings of the ACM on Management of Data</source> (<publisher-loc>New York, NY</publisher-loc>: <publisher-name>Association for Computing Machinery</publisher-name>). doi: <pub-id pub-id-type="doi">10.1145/3588946</pub-id></mixed-citation>
</ref>
<ref id="B58">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Sch&#x000F6;nberger</surname> <given-names>M.</given-names></name> <name><surname>Trummer</surname> <given-names>I.</given-names></name> <name><surname>Mauerer</surname> <given-names>W.</given-names></name></person-group> (<year>2023b</year>). <article-title>Quantum-inspired digital annealing for join ordering</article-title>. <source>Proc. VLDB Endow</source>. <volume>17</volume>, <fpage>511</fpage>&#x02013;<lpage>524</lpage>. doi: <pub-id pub-id-type="doi">10.14778/3632093.3632112</pub-id></mixed-citation>
</ref>
<ref id="B59">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Sch&#x000F6;nberger</surname> <given-names>M.</given-names></name> <name><surname>Trummer</surname> <given-names>I.</given-names></name> <name><surname>Mauerer</surname> <given-names>W.</given-names></name></person-group> (<year>2023c</year>). <article-title>&#x0201C;Quantum optimisation of general join trees,&#x0201D;</article-title> in <source>Joint Workshops at 49th International Conference on Very Large Data Bases (VLDBW&#x00027;23) &#x02014; International Workshop on Quantum Data Science and Management (QDSM&#x00027;23)</source> (<publisher-loc>Vancouver, BC</publisher-loc>).</mixed-citation>
</ref>
<ref id="B60">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Schuetz</surname> <given-names>M. J.</given-names></name> <name><surname>Brubaker</surname> <given-names>J. K.</given-names></name> <name><surname>Katzgraber</surname> <given-names>H. G.</given-names></name></person-group> (<year>2022</year>). <article-title>Combinatorial optimization with physics-inspired graph neural networks</article-title>. <source>Nat. Mach. Intell</source>. <volume>4</volume>, <fpage>367</fpage>&#x02013;<lpage>377</lpage>. doi: <pub-id pub-id-type="doi">10.1038/s42256-022-00468-6</pub-id></mixed-citation>
</ref>
<ref id="B61">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Selinger</surname> <given-names>P. G.</given-names></name> <name><surname>Astrahan</surname> <given-names>M. M.</given-names></name> <name><surname>Chamberlin</surname> <given-names>D. D.</given-names></name> <name><surname>Lorie</surname> <given-names>R. A.</given-names></name> <name><surname>Price</surname> <given-names>T. G.</given-names></name></person-group> (<year>1979</year>). <article-title>&#x0201C;Access path selection in a relational database management system,&#x0201D;</article-title> in <source>Proceedings of the 1979 ACM SIGMOD International Conference on Management of Data, SIGMOD &#x00027;79</source> (<publisher-loc>New York, NY</publisher-loc>: <publisher-name>Association for Computing Machinery</publisher-name>), <fpage>23</fpage>&#x02013;<lpage>34</lpage>. doi: <pub-id pub-id-type="doi">10.1145/582095.582099</pub-id></mixed-citation>
</ref>
<ref id="B62">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Shor</surname> <given-names>P.</given-names></name></person-group> (<year>1994</year>). <article-title>&#x0201C;Algorithms for quantum computation: discrete logarithms and factoring,&#x0201D;</article-title> in <source>Proceedings 35th Annual Symposium on Foundations of Computer Science</source> (<publisher-loc>Santa Fe, NM</publisher-loc>: <publisher-name>IEEE</publisher-name>), <fpage>124</fpage>&#x02013;<lpage>134</lpage>. doi: <pub-id pub-id-type="doi">10.1109/SFCS.1994.365700</pub-id></mixed-citation>
</ref>
<ref id="B63">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Steinbrunn</surname> <given-names>M.</given-names></name> <name><surname>Moerkotte</surname> <given-names>G.</given-names></name> <name><surname>Kemper</surname> <given-names>A.</given-names></name></person-group> (<year>1997</year>). <article-title>Heuristic and randomized optimization for the join ordering problem</article-title>. <source>VLDB J</source>. <volume>6</volume>, <fpage>191</fpage>&#x02013;<lpage>208</lpage>. doi: <pub-id pub-id-type="doi">10.1007/s007780050040</pub-id></mixed-citation>
</ref>
<ref id="B64">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Sz&#x000E9;kely</surname> <given-names>L. A.</given-names></name> <name><surname>Wang</surname> <given-names>H.</given-names></name></person-group> (<year>2005</year>). <article-title>On subtrees of trees</article-title>. <source>Adv. Appl. Math</source>. <volume>34</volume>, <fpage>138</fpage>&#x02013;<lpage>155</lpage>. doi: <pub-id pub-id-type="doi">10.1016/j.aam.2004.07.002</pub-id></mixed-citation>
</ref>
<ref id="B65">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Trummer</surname> <given-names>I.</given-names></name></person-group> (<year>2025</year>). <article-title>&#x0201C;Leveraging quantum computing for optimal data allocation in distributed systems,&#x0201D;</article-title> in <source>Proceedings of the 2nd Workshop on Quantum Computing and Quantum-Inspired Technology for Data-Intensive Systems and Applications, Q-Data &#x00027;25</source> (<publisher-loc>New York, NY</publisher-loc>: <publisher-name>Association for Computing Machinery</publisher-name>), <fpage>10</fpage>&#x02013;<lpage>17</lpage>. doi: <pub-id pub-id-type="doi">10.1145/3736393.3736692</pub-id></mixed-citation>
</ref>
<ref id="B66">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Trummer</surname> <given-names>I.</given-names></name> <name><surname>Koch</surname> <given-names>C.</given-names></name></person-group> (<year>2016</year>). <article-title>Multiple query optimization on the d-wave 2x adiabatic quantum computer</article-title>. <source>Proc. VLDB Endow</source>. <volume>9</volume>, <fpage>648</fpage>&#x02013;<lpage>659</lpage>. doi: <pub-id pub-id-type="doi">10.14778/2947618.2947621</pub-id></mixed-citation>
</ref>
<ref id="B67">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Trummer</surname> <given-names>I.</given-names></name> <name><surname>Koch</surname> <given-names>C.</given-names></name></person-group> (<year>2017</year>). <article-title>&#x0201C;Solving the join ordering problem via mixed integer linear programming,&#x0201D;</article-title> in <source>Proceedings of the 2017 ACM International Conference on Management of Data, SIGMOD &#x00027;17</source> (<publisher-loc>New York, NY</publisher-loc>: <publisher-name>Association for Computing Machinery</publisher-name>), <fpage>1025</fpage>&#x02013;<lpage>1040</lpage>. doi: <pub-id pub-id-type="doi">10.1145/3035918.3064039</pub-id></mixed-citation>
</ref>
<ref id="B68">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Trummer</surname> <given-names>I.</given-names></name> <name><surname>Venturelli</surname> <given-names>D.</given-names></name></person-group> (<year>2024</year>). <article-title>&#x0201C;Leveraging quantum computing for database index selection,&#x0201D;</article-title> in <source>Workshop on Quantum Computing and Quantum-Inspired Technology for Data-Intensive Systems and Applications, Q-Data 2024, Santiago, Chile, June 9-15, 2024</source>, eds. <person-group person-group-type="editor"><name><surname>Sabek</surname> <given-names>I.</given-names></name> <name><surname>Trummer</surname> <given-names>I.</given-names></name> <name><surname>Prestel</surname> <given-names>S.</given-names></name></person-group> (<publisher-loc>New York, NY</publisher-loc>: <publisher-name>ACM</publisher-name>). doi: <pub-id pub-id-type="doi">10.1145/3665225.3665445</pub-id></mixed-citation>
</ref>
<ref id="B69">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Uotila</surname> <given-names>V.</given-names></name></person-group> (<year>2022</year>). <article-title>&#x0201C;Synergy between quantum computers and databases,&#x0201D;</article-title> in <source>of the VLDB 2022 PhD Workshop co-located with the 48th International Conference on Very Large Databases (VLDB 2022), 3186</source> (<publisher-loc>Sydney</publisher-loc>), <fpage>4</fpage>.<pub-id pub-id-type="pmid">40836204</pub-id></mixed-citation></ref>
<ref id="B70">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Uotila</surname> <given-names>V.</given-names></name></person-group> (<year>2024a</year>). <article-title>&#x0201C;Quantum natural language processing application for estimating SQL query metrics,&#x0201D;</article-title> in <source>2024 IEEE International Conference on Quantum Computing and Engineering (QCE), Vol. 2</source> (<publisher-loc>Montreal, QC</publisher-loc>: <publisher-name>IEEE</publisher-name>), <fpage>392</fpage>&#x02013;<lpage>393</lpage>. doi: <pub-id pub-id-type="doi">10.1109/QCE60285.2024.10321</pub-id></mixed-citation>
</ref>
<ref id="B71">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Uotila</surname> <given-names>V.</given-names></name></person-group> (<year>2024b</year>). <article-title>&#x0201C;Tensor decompositions and adiabatic quantum computing for discovering practical matrix multiplication algorithms,&#x0201D;</article-title> in <source>2024 IEEE International Conference on Quantum Computing and Engineering (QCE), Vol. 01</source> (<publisher-loc>Montreal, QC</publisher-loc>: <publisher-name>IEEE</publisher-name>), <fpage>390</fpage>&#x02013;<lpage>401</lpage>. doi: <pub-id pub-id-type="doi">10.1109/QCE60285.2024.00053</pub-id></mixed-citation>
</ref>
<ref id="B72">
<mixed-citation publication-type="web"><person-group person-group-type="author"><name><surname>Uotila</surname> <given-names>V.</given-names></name></person-group> (<year>2025a</year>). <source>Q-join Github Repository</source>. Available online at: <ext-link ext-link-type="uri" xlink:href="https://github.com/valterUo/Q-Join">https://github.com/valterUo/Q-Join</ext-link> (Accessed June 16, 2025).</mixed-citation>
</ref>
<ref id="B73">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Uotila</surname> <given-names>V.</given-names></name></person-group> (<year>2025b</year>). <article-title>&#x0201C;Sql2circuits: estimating cardinalities, execution times, and costs for sql queries with quantum natural language processing,&#x0201D;</article-title> in <source>IEEE International Conference on Quantum Computing and Engineering (QCE)</source> (<publisher-loc>Albuquerque</publisher-loc>).</mixed-citation>
</ref>
<ref id="B74">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Uotila</surname> <given-names>V.</given-names></name> <name><surname>Julia</surname> <given-names>R.</given-names></name> <name><surname>Zhao</surname> <given-names>B.</given-names></name></person-group> (<year>2025</year>). <article-title>&#x0201C;Higher-order portfolio optimization with quantum approximate optimization algorithm,&#x0201D;</article-title> in <source>2025 IEEE International Conference on Quantum Computing and Engineering (QCE)</source> (<publisher-loc>Albuquerque</publisher-loc>: <publisher-name>IEEE</publisher-name>).</mixed-citation>
</ref>
<ref id="B75">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Uotila</surname> <given-names>V.</given-names></name> <name><surname>Lu</surname> <given-names>J.</given-names></name></person-group> (<year>2023</year>). <article-title>&#x0201C;Quantum annealing method for dynamic virtual machine and task allocation in cloud infrastructures from sustainability perspective,&#x0201D;</article-title> in <source>2023 IEEE 39th International Conference on Data Engineering Workshops (ICDEW)</source> (<publisher-loc>Anaheim, CA</publisher-loc>: <publisher-name>IEEE</publisher-name>), <fpage>105</fpage>&#x02013;<lpage>110</lpage>. doi: <pub-id pub-id-type="doi">10.1109/ICDEW58674.2023.00023</pub-id></mixed-citation>
</ref>
<ref id="B76">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Verchere</surname> <given-names>Z.</given-names></name> <name><surname>Elloumi</surname> <given-names>S.</given-names></name> <name><surname>Simonetto</surname> <given-names>A.</given-names></name></person-group> (<year>2023</year>). <article-title>&#x0201C;Optimizing variational circuits for higher-order binary optimization,&#x0201D;</article-title> in <source>2023 IEEE International Conference on Quantum Computing and Engineering (QCE)</source> (<publisher-loc>Los Alamitos, CA</publisher-loc>: <publisher-name>IEEE Computer Society</publisher-name>), <fpage>19</fpage>&#x02013;<lpage>25</lpage>. doi: <pub-id pub-id-type="doi">10.1109/QCE57702.2023.00011</pub-id><pub-id pub-id-type="pmid">34597099</pub-id></mixed-citation></ref>
<ref id="B77">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Vogrin</surname> <given-names>M.</given-names></name> <name><surname>Vogrin</surname> <given-names>R.</given-names></name> <name><surname>Groppe</surname> <given-names>S.</given-names></name> <name><surname>Groppe</surname> <given-names>J.</given-names></name></person-group> (<year>2024</year>). <article-title>&#x0201C;Supervised learning on relational databases with quantum graph neural networks,&#x0201D;</article-title> in <source>QDSM&#x00040;VLDB</source> (<publisher-loc>Guangzhou</publisher-loc>)</mixed-citation>
</ref>
<ref id="B78">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Wang</surname> <given-names>B.-Y.</given-names></name> <name><surname>Cui</surname> <given-names>X.</given-names></name> <name><surname>Zeng</surname> <given-names>Q.</given-names></name> <name><surname>Zhan</surname> <given-names>Y.</given-names></name> <name><surname>Yung</surname> <given-names>M.-H.</given-names></name> <name><surname>Shi</surname> <given-names>Y.</given-names></name> <etal/></person-group>. (<year>2025</year>). <article-title>Speedup of high-order unconstrained binary optimization using quantum z 2 lattice gauge theory</article-title>. <source>Commun. Phys</source>. <volume>8</volume>:<fpage>150</fpage>. doi: <pub-id pub-id-type="doi">10.1038/s42005-025-02072-7</pub-id></mixed-citation>
</ref>
<ref id="B79">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Wendin</surname> <given-names>G.</given-names></name></person-group> (<year>2017</year>). <article-title>Quantum information processing with superconducting circuits: a review</article-title>. <source>Rep. Prog. Phys</source>. <volume>80</volume>:<fpage>106001</fpage>. doi: <pub-id pub-id-type="doi">10.1088/1361-6633/aa7e1a</pub-id><pub-id pub-id-type="pmid">28682303</pub-id></mixed-citation></ref>
<ref id="B80">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Willsch</surname> <given-names>D.</given-names></name> <name><surname>Willsch</surname> <given-names>M.</given-names></name> <name><surname>Gonzalez Calaza</surname> <given-names>C. D.</given-names></name> <name><surname>Jin</surname> <given-names>F.</given-names></name> <name><surname>De Raedt</surname> <given-names>H.</given-names></name> <name><surname>Svensson</surname> <given-names>M.</given-names></name> <etal/></person-group>. (<year>2022</year>). <article-title>Benchmarking advantage and d-wave 2000q quantum annealers with exact cover problems</article-title>. <source>Quantum Inf Process</source>. <volume>21</volume>:<fpage>141</fpage>. doi: <pub-id pub-id-type="doi">10.1007/s11128-022-03476-y</pub-id></mixed-citation>
</ref>
<ref id="B81">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Winker</surname> <given-names>T.</given-names></name> <name><surname>&#x000C7;alikyilmaz</surname> <given-names>U.</given-names></name> <name><surname>Gruenwald</surname> <given-names>L.</given-names></name> <name><surname>Groppe</surname> <given-names>S.</given-names></name></person-group> (<year>2023a</year>). <article-title>&#x0201C;Quantum machine learning for join order optimization using variational quantum circuits</article-title> in <source>Proceedings of the International Workshop on Big Data in Emergent Distributed Environments, BiDEDE &#x00027;23</source> (<publisher-loc>New York, NY</publisher-loc>: <publisher-name>Association for Computing Machinery</publisher-name>), <fpage>1</fpage>&#x02013;<lpage>7</lpage>. doi: <pub-id pub-id-type="doi">10.1145/3579142.3594299</pub-id></mixed-citation>
</ref>
<ref id="B82">
<mixed-citation publication-type="book"><person-group person-group-type="author"><name><surname>Winker</surname> <given-names>T.</given-names></name> <name><surname>Groppe</surname> <given-names>S.</given-names></name> <name><surname>Uotila</surname> <given-names>V.</given-names></name> <name><surname>Yan</surname> <given-names>Z.</given-names></name> <name><surname>Lu</surname> <given-names>J.</given-names></name> <name><surname>Franz</surname> <given-names>M.</given-names></name> <etal/></person-group>. (<year>2023b</year>). <article-title>&#x0201C;Quantum machine learning: foundation, new techniques, and opportunities for database research,&#x0201D;</article-title> in <source>Companion of the 2023 International Conference on Management of Data, SIGMOD &#x00027;23</source> (<publisher-loc>New York, NY</publisher-loc>: <publisher-name>Association for Computing Machinery</publisher-name>), <fpage>45</fpage>&#x02013;<lpage>52</lpage>. doi: <pub-id pub-id-type="doi">10.1145/3555041.3589404</pub-id></mixed-citation>
</ref>
<ref id="B83">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Zhong</surname> <given-names>H.-S.</given-names></name> <name><surname>Wang</surname> <given-names>H.</given-names></name> <name><surname>Deng</surname> <given-names>Y.-H.</given-names></name> <name><surname>Chen</surname> <given-names>M.-C.</given-names></name> <name><surname>Peng</surname> <given-names>L.-C.</given-names></name> <name><surname>Luo</surname> <given-names>Y.-H.</given-names></name> <etal/></person-group>. (<year>2020</year>). <article-title>Quantum computational advantage using photons</article-title>. <source>Science</source> <volume>370</volume>, <fpage>1460</fpage>&#x02013;<lpage>1463</lpage>. doi: <pub-id pub-id-type="doi">10.1126/science.abe8770</pub-id><pub-id pub-id-type="pmid">33273064</pub-id></mixed-citation></ref>
<ref id="B84">
<mixed-citation publication-type="journal"><person-group person-group-type="author"><name><surname>Zhu</surname> <given-names>Q.</given-names></name> <name><surname>Cao</surname> <given-names>S.</given-names></name> <name><surname>Chen</surname> <given-names>F.</given-names></name> <name><surname>Chen</surname> <given-names>M.-C.</given-names></name> <name><surname>Chen</surname> <given-names>X.</given-names></name> <name><surname>Chung</surname> <given-names>T.-H.</given-names></name> <etal/></person-group>. (<year>2021</year>). <article-title>Quantum computational advantage via 60-qubit 24-cycle random circuit sampling</article-title>. <source>arXiv [preprint]</source>. arXiv:2109.03494. doi: <pub-id pub-id-type="doi">10.48550/arXiv:2109.03494</pub-id><pub-id pub-id-type="pmid">36546072</pub-id></mixed-citation></ref>
</ref-list>
<fn-group>
<fn fn-type="custom" custom-type="edited-by" id="fn0001">
<p>Edited by: <ext-link ext-link-type="uri" xlink:href="https://loop.frontiersin.org/people/1234714/overview">Daowen Qiu</ext-link>, Sun Yat-sen University, China</p>
</fn>
<fn fn-type="custom" custom-type="reviewed-by" id="fn0002">
<p>Reviewed by: <ext-link ext-link-type="uri" xlink:href="https://loop.frontiersin.org/people/81712/overview">Prasanta Panigrahi</ext-link>, Indian Institute of Science Education and Research-Kolkata, India; <ext-link ext-link-type="uri" xlink:href="https://loop.frontiersin.org/people/3131184/overview">Hao Li</ext-link>, First Affiliated Hospital of Sun Yat-sen University, China</p>
</fn>
</fn-group>
</back>
</article>