Computer-implemented method, computer system, and computer program product for learned join cardinality estimation using a join graph representation

Abstract

The present invention includes techniques for providing a learned connectivity cardinality estimate using a connectivity graph representation. A non-limiting example method includes constructing a connectivity cardinality estimation model. This model can be constructed by: generating a training query having a known connectivity cardinality; generating an adjacency matrix encoding a connectivity graph of the training query; encoding one side of a diagonal axis of the adjacency matrix; and training the connectivity cardinality estimation model using the encoded adjacency matrix and the known connectivity cardinality. The method includes performing inference using the connectivity cardinality estimation model. The inference includes a predicted connectivity cardinality for a query. The method includes executing a query execution plan for the query using the predicted connectivity cardinality.

Description

Learned Join Cardinality Estimation Represented Using a Join Graph The present invention generally relates to database design, and more particularly, to computer systems, computer-implemented methods, and computer program products for providing learned join cardinality estimation represented using a join graph. Relational database management systems (RDBMSs) often rely on Structured Query Language (SQL) to manage data stored in relational databases. RDBMSs typically include single-row statistics data that are typically collected on individual rows in a so-called relationship. The relationship may include tuples and / or attributes that describe relationships within or between tables in the relational database and / or define characteristics. For example, the relationship may include data values on a table, and the relational database may store the data values as a relationship or table. A collection of relationships or tables may be stored on the database as a relational model. Queries can be executed against a relational database using an RDBMS. A query is a specific request or command issued to the RDBMS to retrieve, manipulate, and / or update data stored in the relational database. Queries allow users to interact with the database and perform various operations, such as retrieving specific records, filtering data based on certain criteria, aggregating information, joining tables, and modifying data. Queries are typically written using SQL, which provides a standardized syntax and set of commands for interacting with the database via the query. Cardinality estimation refers to the process of estimating the number of rows that will be returned by a query operation and is an essential aspect of query optimization, index selection, resource allocation, and execution planning in an RDBMS. When a query is executed, the database or query optimizer (e.g., a component of the RDBMS) analyzes the query and determines the most efficient execution plan. To do this, the optimizer needs to estimate the cardinality of the intermediate and final results of the query. The optimizer uses statistical information, such as row histograms, single-row statistics, and multi-row correlations, to make these estimates. The cardinality of a particular row or set of rows represents the number of unique values for that particular row or set of rows. For example, in a customer table, the cardinality of the "customer_id" row represents the number of unique customers in the table. In contrast, the cardinality of a query result set indicates the number of distinct rows or tuples that will be returned. In the context of query optimization, the join cardinality estimation problem refers to the challenge of accurately estimating the number of rows that will result from joining two or more tables in a database query. Join cardinality estimation is crucial for the optimizer to generate an efficient query execution plan. The optimizer uses join cardinality estimation to evaluate different access paths, join algorithms, and plan alternatives to select the most efficient execution strategy. Accurate join cardinality estimation helps the optimizer more accurately estimate the costs of different plan options, such as the number of disk I / O operations, CPU utilization, and memory requirements. An ideal join cardinality estimation method satisfies several properties: it effectively produces high-quality query plans, which are efficient because it minimizes the estimated latency, can be generalized to new queries, and is easy to deploy because it has a relatively small model size, fast training time, and the ability to scale with the number of tables. Unfortunately, accurately estimating join cardinality is challenging due to several factors, such as unknown or changing data distributions, unknown correlations between joined rows, and filters / predicates in the query. Existing join cardinality estimation techniques use one or both of the following two general categories to solve the join cardinality estimation problem: classical and learning. When estimating the cardinality of a join query, neither classical nor previous learning-based methods produce satisfactory accuracy. These techniques often rely on simplifying assumptions, which lead to ineffective cardinality estimation, or require building and training large models to understand data distributions, data correlations, etc., resulting in long planning times and a lack of generality across queries. Embodiments of the present invention are directed to techniques for providing a learned join cardinality estimation using a join graph representation. A non-limiting example method includes building a join cardinality estimation model. The model can be built by: generating a training query having a known join cardinality; generating an adjacency matrix encoding a join graph of the training query; encoding one side of a diagonal axis of the adjacency matrix; and using the encoded adjacency matrix and the known join cardinality to train the join cardinality estimation model. The method includes performing an inference using the join cardinality estimation model. The inference includes a predicted join cardinality for a query. The method includes performing a query execution plan for the query using the predicted join cardinality. Advantageously, an encoding mechanism demonstrating strong generalization ability is realized by utilizing a join cardinality estimation model in this way. By using abstract statistical information about the joins of tables, local predicates, and queries, the structure of the join graph is used rather than its specific elements. Thus, for a new query, the join cardinality can be inferred based on the similarity of the join graph and the abstract information about the tables and predicates involved. In some embodiments, performing the inference includes: generating an adjacency matrix encoding a join graph of the query; encoding one side of a diagonal axis of the adjacency matrix; inputting the encoded adjacency matrix into the join cardinality estimation model; and receiving the predicted join cardinality as an output. Advantageously, this configuration provides efficient join cardinality estimation for individual queries because the model can be pre-trained offline. In some embodiments, training the join cardinality estimation model includes adjusting one or more weights of the join cardinality estimation model until an output predicted join cardinality of the training query matches the known join cardinality within a predetermined threshold. Advantageously, training the join cardinality estimation model in this way provides relatively fast convergence (consistent with known test inputs). ​In some embodiments, for a given query that connects one of a set of n tables, each adjacency matrix can be defined as an n×n matrix, where if table i is connected to table j, then a value at a position ( i, j) in the matrix is 1, otherwise 0. Advantageously, this configuration allows the structure of a given query to be encoded in a manner that can be easily provided to a model (e.g., the join cardinality estimation model). In some embodiments, building the join cardinality estimation model further includes: generating an additional adjacency matrix encoding a join type of the training query; encoding one side of a diagonal axis of the additional adjacency matrix into a join type adjacency matrix; and concatenating the encoded join type adjacency matrix with the encoded join graph before training the join cardinality estimation model. Advantageously, this technique allows matrix encoding to consider join type data in the query. In some embodiments, building the join cardinality estimation model further includes: generating an additional adjacency matrix encoding a join operator of the training query; encoding one side of a diagonal axis of the additional adjacency matrix; and concatenating the encoded adjacency matrix of the join operator with the encoded join graph before training the join cardinality estimation model. Advantageously, this technique allows matrix encoding to consider join operator data in the query. In some embodiments, building the join cardinality estimation model further includes: generating an additional adjacency matrix that encodes a ratio of the cardinality of the join rows on each side of a join in the training query to the table cardinality; encoding one side of a diagonal axis of the additional adjacency matrix into a row-to-table encoded adjacency matrix; and concatenating the row-to-table encoded adjacency matrix with the encoded join graph before training the join cardinality estimation model. Advantageously, this technique allows matrix encoding to consider the ratio of the row cardinality to the table cardinality in the query. In some embodiments, building the join cardinality estimation model further includes: generating an additional adjacency matrix that encodes a ratio of the cardinality of the left table to the right table of a join in the training query; encoding one side of a diagonal axis of the additional adjacency matrix into a table cardinality encoded adjacency matrix; and concatenating the table cardinality encoded adjacency matrix with the encoded join graph before training the join cardinality estimation model. Advantageously, this technique allows matrix encoding to consider the ratio of the table cardinalities in the query. In some embodiments, constructing the join cardinality estimation model further includes: generating an additional adjacency matrix that encodes a measure of the skewness of each join row of a join for one of the training queries; encoding one side of a diagonal axis of the additional adjacency matrix into an encoded skewness adjacency matrix; and concatenating the encoded skewness adjacency matrix with an encoded join graph before training the join cardinality estimation model. Advantageously, this technique allows matrix encoding to account for the skewness of joins in the query. In some embodiments, constructing the join cardinality estimation model further includes: generating an additional adjacency matrix that encodes a measure of the selectivity of join predicates of a join for one of the training queries; encoding one side of a diagonal axis of the additional adjacency matrix into an encoded join factor adjacency matrix; and concatenating the encoded join factor adjacency matrix with an encoded join graph before training the join cardinality estimation model. Advantageously, this technique allows matrix encoding to account for join selectivity in the absence of local predicates and provides an indication of whether the number of rows will expand, decrease, or remain the same relative to the Cartesian product of the columns in two tables. In some embodiments, constructing the join cardinality estimation model further includes: generating an additional adjacency matrix that encodes whether one side of the values of a join row is a superset of the other side of the values of the join row for the training query; encoding one side of a diagonal axis of the additional adjacency matrix into an encoded inclusion factor adjacency matrix; and concatenating the encoded inclusion factor adjacency matrix with an encoded join graph before training the join cardinality estimation model. Advantageously, this technique allows matrix encoding to account for the inclusion factor of joins in the query. In some embodiments, constructing the join cardinality estimation model further includes: generating an additional adjacency matrix that encodes the cardinality of each base data table of a join for one of the training queries and the selectivity of local predicates on those base data tables; encoding one side of a diagonal axis of the additional adjacency matrix into an encoded node configuration adjacency matrix; and concatenating the encoded node coordinate adjacency matrix with an encoded join graph before training the join cardinality estimation model. Advantageously, this technique allows matrix encoding to account for other characteristics of the query that are attributes of the tables rather than attributes of the joins. Embodiments of the present invention are directed to techniques for providing a learned join cardinality estimation represented using a join graph. A non-limiting example method includes: generating a training query having a known join cardinality; generating an adjacency matrix that encodes a join graph of the training query; encoding one side of a diagonal axis of the adjacency matrix; and training the join cardinality estimation model using the encoded join graph and the known join cardinality. Advantageously, training a join cardinality estimation model in this manner achieves an efficient join cardinality estimation mechanism that demonstrates strong generalization ability. Embodiments of the present invention are directed to techniques for providing learned join cardinality estimation using a join graph representation. A non-limiting example method includes performing an inference using a trained join cardinality estimation model. The inference includes a predicted join cardinality for a query. Performing the inference includes: generating an adjacency matrix of a join graph encoding the query; encoding one side of a diagonal axis of the adjacency matrix into an encoded adjacency matrix; inputting the encoded adjacency matrix into the join cardinality estimation model; and receiving the predicted join cardinality as an output. The method includes performing a query execution plan for the query using the predicted join cardinality. Advantageously, using a trained model in this way for join cardinality estimation achieves an efficient join cardinality estimation mechanism demonstrating strong generalization ability. Other embodiments of the present invention implement the features of the methods described above in computer systems and computer program products. Additional technical features and benefits are realized through the techniques of the present invention. Embodiments and aspects of the present invention are described in detail herein and are considered part of the claimed subject matter. For a better understanding, reference is made to the embodiments and the drawings. Accurately estimating join cardinality is challenging due to several factors such as unknown or changing data distributions, unknown correlations between join rows, and filters / predicates in the query. For example, a database or query optimizer needs to make assumptions about the distribution of data within the tables involved in a join. However, the actual data distribution may not be known in advance or may change over time. Skewed data distributions, where a few values are more common than others, can significantly affect cardinality estimation. The optimizer must also consider the degree of correlation (if any) between multiple join rows. If the values in the join rows are highly correlated, the cardinality of the join result will be different from the cardinality estimated by a simple multiplication of the individual table selectivities based on the individual join predicates. Accurately determining this correlation is challenging, especially when there is no defined explicit foreign key relationship. Other challenges include the presence of filters (predicates) in the query, which adds another level of complexity to cardinality estimation. The optimizer needs to accurately estimate the selectivity of each predicate to predict the number of rows that will satisfy the join conditions. If the selectivity is underestimated, the optimizer may choose an inefficient plan that produces too many intermediate results. Additionally, different join algorithms, such as nested loop joins, hash joins, and merge joins, have different behaviors depending on the cardinality of the input tables and the resulting cardinality after applying the join predicates. The optimizer needs to accurately estimate the join cardinality to determine which join algorithm to choose. To solve the join cardinality estimation problem, database systems employ various techniques. For example, histograms provide a statistical overview of the data distribution within a row. By analyzing the histograms, the optimizer can better estimate the number of distinct values and the frequency of each value, thus assisting in cardinality estimation. Other techniques include sampling, which involves examining a subset of the data to estimate the characteristics of the entire dataset. By analyzing a representative sample, the optimizer can infer the data distribution and correlations, thus producing more accurate cardinality estimates. The optimizer can also use a cost model to assign costs to different query plans based on the estimated cardinality. In such configurations, the optimizer utilizes different join orders and algorithms, assigns costs to each plan, and selects the plan with the lowest cost. Iterative algorithms, such as dynamic programming and genetic algorithms, are typically used to efficiently search the plan space. Database systems can maintain statistics about tables (including row histograms) to assist in cardinality estimation. These statistics are collected periodically or on demand based on the observed data patterns and correlations, thus providing valuable information about data distribution and correlations. As previously described, existing join cardinality estimation techniques use one or both of the following two general categories to solve the join cardinality estimation problem: classical and learning. When estimating the cardinality of a join query, neither classical nor previously learning-based methods produce satisfactory accuracy. These techniques often rely on simplifying assumptions, which lead to ineffective cardinality estimation, or require building and training large models to understand data distribution, data correlations, etc., which leads to long planning times and lack of generality across queries. This disclosure introduces new methods, computing systems, and computer program products for providing learned join cardinality estimation using a join graph representation. The join graph representation is built from two constructs: an adjacency matrix and node coordinates. The adjacency matrix of the join graph is used as a building block to encode information about the join. Other characteristics of the query that are attributes of the tables rather than attributes of the join, such as the cardinality of the base tables and the selectivity of the native predicates on the base tables, are encoded as node coordinates. In some embodiments, the training queries are encoded into vectors that can be consumed by a machine learning model. The join cardinality estimation framework using the join graph representation according to one or more embodiments described herein provides various technical advantages over prior join cardinality estimation methods. Notably, each of the join graph features extracted according to one or more embodiments plays an important role in allowing the base model to estimate the join cardinality. The join cardinality estimation framework described herein is not limited to certain types of operators or types of join queries and can be generalized to any join graph. Additionally, the skewness of the predicate rows is extracted using the skewness coefficient. Other advantages are possible. Different from previous methods, the join cardinality estimation framework described herein considers the scenario where the set of row values on one side of the join is not a subset of the row values on the other side. By explicitly capturing pairwise correlations, the model can consider such correlations while computing composite selectivity from local predicates. Advantageously, the presented join cardinality estimation framework utilizes an encoding mechanism that demonstrates strong generalization ability. By using abstract statistical information about tables, local predicates, and joins, the structure of the join graph is used rather than its specific elements. Thus, for a new query, the join cardinality can be inferred based on the similarity of the join graph and the abstract information about the tables and predicates involved. Other methods often need to collect join samples as input to their respective models. Collecting such samples and computing joins is extremely expensive and not feasible in a production environment. The solution of the present invention does not require any samples as input to the model to compute join cardinality estimation, and is thus relatively more efficient, such that the additional load incurred at query optimization time when integrating the model usage in a query optimizer is negligible. In some embodiments, the join cardinality estimation framework described herein includes continuous learning through runtime feedback. Continuous learning through runtime feedback results in the automatic improvement (adaptation) of the model over time in view of runtime changes in the schema description, data, and workload. Previous methods had to extract all tables and rows in the database and needed to rebuild and retrain the respective models from scratch to address any changes in the schema description. This retraining induced by schema description changes is very expensive and the model is degraded to be used with a static database. Although some methods utilize join samples to help account for potential changes in data over time, considering such changes every time a query is compiled is extremely expensive compared to the runtime feedback method described herein, which will again continuously train in the background over time with minimal impact. Various aspects of the present disclosure are described by narrative text, flowcharts, block diagrams of computer systems, and / or block diagrams of machine logic included in embodiments of a computer program product (CPP). With respect to any flowchart, depending on the technology involved, the operations may be performed in an order different from the order shown in a given flowchart. For example, again depending on the technology involved, two operations shown in consecutive flowchart blocks may be performed in reverse order, performed as a single integrated step, performed in parallel, or performed in a manner that at least partially overlaps in time. A computer program product embodiment (referred to as "CPP embodiment" or "CPP") is a term used in this disclosure to describe any set of one or more storage media (also referred to as "media") collectively included in a collection of one or more storage devices, which collectively include machine-readable program code corresponding to instructions and / or data for performing computer operations specified in a given CPP requirement. A "storage device" is any tangible device that can retain and store instructions for use by a computer processor. By way of non-limiting example, a computer-readable storage medium can be an electronic storage medium, a magnetic storage medium, an optical storage medium, an electromagnetic storage medium, a semiconductor storage medium, a mechanical storage medium, or any suitable combination of the foregoing. Some known types of storage devices that include such media include: magnetic disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), compact disc read-only memory (CD-ROM), digital versatile disc (DVD), memory stick, floppy disk, mechanically encoded devices (such as punched cards or pits / pads formed on the main surface of an optical disc), or any suitable combination of the foregoing. As used in this disclosure, a computer-readable storage medium should not be construed to store in the form of a transient signal itself, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide, optical pulses passing through an optical cable, electrical signals conveyed through a wire, and / or other transmission media. As those skilled in the art will appreciate, data typically moves at some occasional time points during the normal operation of a storage device (such as during access, disk defragmentation, or garbage collection), but this does not render the storage device transient because the data is not transient when it is stored. Referring now to FIG. 1, computing environment 100 contains an example of an environment for executing at least some of the computer code involved in performing the method of the present invention, such as connection cardinality estimation module 150 (also referred to herein as block 150). In addition to block 150, computing environment 100 also includes, for example, computer 101, wide area network (WAN) 102, end-user device (EUD) 103, remote server 104, public cloud 105, and private cloud 106. In this embodiment, computer 101 includes: processor group 110 (including processing circuitry 120 and cache memory 121), communication fabric 111, volatile memory 112, persistent storage 113 (including operating system 122 and block 150 identified above), peripheral device group 114 (including user interface (UI) device group 123, storage 124, and Internet of Things (IoT) sensor group 125), and network module 115. Remote server 104 includes remote database 130. Public cloud 105 includes gateway 140, cloud orchestration module 141, host physical machine group 142, virtual machine group 143, and container group 144. Computer 101 can take the form of a desktop computer, laptop computer, tablet computer, smartphone, smartwatch, or other portable computer, mainframe computer, quantum computer, or any other form of computer or mobile device now known or to be developed in the future that is capable of running programs, accessing networks, or querying databases such as remote database 130. As is well understood in the field of computer technology, and depending on the technology, the performance of computer-implemented methods can be distributed among multiple computers and / or between multiple locations. On the other hand, in this presentation of computing environment 100, the discussion focuses on a single computer, specifically computer 101, to keep the presentation as simple as possible. Computer 101 can be located in the cloud, although it is not shown in the cloud in FIG. 1. On the other hand, except to the extent that it can be affirmatively indicated, there is no requirement for computer 101 to be in the cloud. Processor group 110 includes one or more computer processors of any type now known or to be developed in the future. Processing circuitry 120 can be distributed across multiple packages, such as multiple coordinated integrated circuit chips. Processing circuitry 120 can implement multiple processor threads and / or multiple processor cores. Cache memory 121 is memory located within the processor chip package and is typically used for data or code that can be quickly accessed by threads or cores running on processor group 110. Cache memory is typically organized into multiple levels depending on its relative proximity to the processing circuitry. Alternatively, some or all of the cache memory for processor group can be located "off-chip". In some computing environments, processor group 110 can be designed to work with qubits and perform quantum computing. Computer-readable program instructions are typically loaded onto computer 101 so that the processor group 110 of computer 101 executes a series of operational steps and thereby affects the computer-implemented method, such that the instructions thus executed will embody the flowchart of the computer-implemented method included in this document and / or the method specified in the narrative description (collectively referred to as "the inventive method"). These computer-readable program instructions are stored in various types of computer-readable storage media, such as cache memory 121 and other storage media discussed below. The program instructions and associated data are accessed by the processor group 110 to control and direct the performance of the inventive method. In computing environment 100, at least some of the instructions for executing the inventive method may be stored in block 150 in persistent storage 113. Communication network architecture 111 is a signal conduction path that allows various components of computer 101 to communicate with each other. Typically, this network architecture is made up of switches and conductive paths, such as switches and conductive paths that make up a bus, a bridge, a physical input / output port, and the like. Other types of signal communication paths may be used, such as fiber optic communication paths and / or wireless communication paths. Volatile memory 112 is any type of volatile memory known now or to be developed in the future. Examples include dynamic random access memory (RAM) or static RAM. Typically, volatile memory is characterized by random access, but this is not required unless affirmatively indicated. In computer 101, volatile memory 112 is located in a single package and inside computer 101, but alternatively or additionally, volatile memory may be distributed across multiple packages and / or located externally relative to computer 101. Persistent storage 113 is any form of non-volatile storage for a computer known now or to be developed in the future. The non-volatility of this storage means that stored data is maintained regardless of whether power is supplied to computer 101 and / or directly to persistent storage 113. Persistent storage 113 may be read-only memory (ROM), but typically at least a portion of the persistent storage allows data to be written, deleted, and rewritten. Some familiar forms of persistent storage include magnetic disks and solid-state storage devices. Operating system 122 may take several forms, such as various known proprietary operating systems or open-source portable operating system interface-type operating systems that employ a kernel. The code included in block 150 typically includes at least some of the computer code involved in executing the inventive method. The peripheral device group 114 includes the peripheral device group of the computer 101. The data communication connection between the peripheral devices and other components of the computer 101 can be implemented in various ways, such as Bluetooth connection, near-field communication (NFC) connection, connection by a cable (such as a universal serial bus (USB) type cable), plug-in connection (for example, a secure digital (SD) card), connection through a local communication network, and even connection through a wide area network such as the Internet. In various embodiments, the UI device group 123 may include components such as a display screen, a speaker, a microphone, wearable devices (such as goggles and smart watches), a keyboard, a mouse, a printer, a touchpad, a game controller, and a tactile device. The storage 124 is an external storage, such as an external hard drive or an insertable storage such as an SD card. The storage 124 can be persistent and / or volatile. In some embodiments, the storage 124 may take the form of a quantum computing storage device for storing data in the form of qubits. In embodiments where the computer 101 needs to have a large amount of storage (for example, when storing and managing a large database on the local side of the computer 101), this storage can be provided by a peripheral storage device designed to store an extremely large amount of data, such as a storage area network (SAN) shared by multiple geographically distributed computers. The IoT sensor group 125 consists of sensors that can be used in Internet of Things applications. For example, one sensor can be a thermometer, and another sensor can be a motion detector. The network module 115 is a collection of computer software, hardware, and firmware that allows the computer 101 to communicate with other computers through the WAN 102. The network module 115 may include: hardware, such as a modem or a Wi-Fi transceiver; software for packetizing and / or depacketizing data for communication network transmission; and / or web browser software for communicating data via the Internet. In some embodiments, the network control function and the network forwarding function of the network module 115 are executed on the same physical hardware device. In other embodiments (for example, embodiments using software-defined network connection (SDN)), the control function and the forwarding function of the network module 115 are executed on physically separate devices so that the control function manages several different network hardware devices. The computer-readable program instructions for executing the method of the present invention can generally be downloaded to the computer 101 from an external computer or an external storage device through a network adapter or a network interface included in the network module 115. The WAN 102 is any wide area network (e.g., the Internet) that is capable of communicating computer data over non-local distances by any technology now known or to be developed in the future for conveying computer data. In some embodiments, the WAN may be replaced and / or supplemented by a local area network (LAN) designed to communicate data between devices located in an area such as a Wi-Fi network. The WAN and / or LAN typically includes computer hardware such as copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and edge servers. The end user device (EUD) 103 is any computer system used and controlled by an end user (e.g., a customer of the enterprise operating the computer 101) and may take any of the forms discussed above in connection with the computer 101. The EUD 103 typically receives helpful and useful data from the operation of the computer 101. For example, in the hypothetical situation where the computer 101 is designed to provide recommendations to an end user, such a recommendation will typically be communicated from the network module 115 of the computer 101 to the EUD 103 via the WAN 102. In this way, the EUD 103 can display or otherwise present the recommendation to the end user. In some embodiments, the EUD 103 may be a client device such as a thin client, a thick client, a mainframe computer, a desktop computer, and so on. The remote server 104 is any computer system that provides at least some data and / or functionality to the computer 101. The remote server 104 may be controlled and used by the same entity that operates the computer 101. The remote server 104 represents a machine that collects and stores helpful and useful data for use by other computers such as the computer 101. For example, in the hypothetical situation where the computer 101 is designed and programmed to provide recommendations based on historical data, then such historical data may be provided from the remote database 130 of the remote server 104 to the computer 101. The public cloud 105 is any computer system available for use by multiple entities, which provides computer system resources and / or other computer capabilities, in particular the on-demand availability of data storage (cloud storage) and computing power, without the need for direct active management by the user. Cloud computing typically utilizes resource sharing to achieve coherence and economies of scale. The direct and active management of the computing resources of the public cloud 105 is performed by the computer hardware and / or software of the cloud orchestration module 141. The computing resources provided by the public cloud 105 are typically implemented by virtual computing environments running on various computers that make up the host physical machine group 142, which is the entirety of the physical computers within and / or available for the public cloud 105. The virtual computing environment (VCE) typically takes the form of virtual machines from the virtual machine group 143 and / or containers from the container group 144. It should be understood that these VCEs can be stored as images and can be transferred among and between various physical machine hosts, either as images or after the instantiation of the VCE. The cloud orchestration module 141 manages the transfer and storage of the images, deploys new instantiations of the VCE, and manages the active instantiations of the VCE deployment. The gateway 140 is a collection of computer software, hardware, and firmware that allows the public cloud 105 to communicate through the WAN 102. Some further explanations of the virtualized computing environment (VCE) will now be provided. The VCE can be stored as an "image". A new active example of the VCE can be instantiated from the image. Two familiar types of VCEs are virtual machines and containers. A container is a VCE that uses operating system-level virtualization. This refers to an operating system feature where the kernel allows the existence of multiple isolated examples of user space, known as containers. From the perspective of the programs running within, these isolated examples of user space typically appear as real computers. A computer program running on a normal operating system can utilize all the resources of that computer, such as connected devices, files and folders, network shares, CPU power, and quantifiable hardware capabilities. However, a program running inside a container can only use the contents of the container and the devices assigned to the container, a feature known as containerization. The private cloud 106 is similar to the public cloud 105, except that the computing resources are only available for use by a single enterprise. Although the private cloud 106 is depicted as communicating with the WAN 102, in other embodiments, the private cloud can be completely disconnected from the Internet and only accessible through a local / private network. A hybrid cloud is a composition of multiple clouds of different types (e.g., private, community, or public cloud types), often implemented by different providers separately. Each of the multiple clouds remains a separate and discrete entity, but the larger hybrid cloud architecture is bound together by standardized or proprietary technologies that enable orchestration, management, and / or data / application portability between the multiple constituent clouds. In this embodiment, both the public cloud 105 and the private cloud 106 are part of the larger hybrid cloud. It should be understood that the block diagram of FIG. 1 is not intended to indicate that the computing environment 100 will include all of the components shown in FIG. 1. Instead, the computing environment 100 may include any suitable fewer or additional components not shown in FIG. 1 (e.g., additional memory components, embedded controllers, modules, additional network interfaces, etc.). Additionally, the embodiments described herein with respect to the computing environment 100 may be implemented by any suitable logic, where in various embodiments, as mentioned herein, the logic may include any suitable combination of hardware (e.g., processors, embedded controllers, or application specific integrated circuits, among others), software (e.g., applications, among others), firmware, or any combination of hardware, software, and firmware. In some embodiments, the join cardinality estimation module 150 includes a model trained to perform join cardinality estimation based on a join graph representation. A system for training and using a machine learning model for join cardinality estimation based on a join graph representation is now described with reference to FIG. 2. Specifically, FIG. 2 depicts a block diagram of the components of a machine learning training and inference system (e.g., the join cardinality estimation module 150) according to one or more embodiments described herein. In some embodiments, the join cardinality estimation module 150 performs training 202 and inference 204. During training 202, the training engine 216 trains a model (e.g., the trained model 218) to perform a task of estimating the join cardinality of a query using a join graph representation. Inference 204 is a process of implementing the trained model 218 to perform a task of estimating the join cardinality of a query for a query made in the context of a larger system 226 (e.g., the computing environment 100 of FIG. 1). Training 202 begins with training data 212, which may be structured or unstructured data. According to one or more embodiments described herein, the training data 212 includes queries from a query workload. The training engine 216 receives the training data 212 and an untrained model 214. The untrained model 214 represents a model that is untrained (i.e., before training) underlying model. The untrained model 214 may have default weights and biases that may be adjusted during training. It should be understood that the untrained model 214 may be selected from many different model forms, such as (for example) fully connected neural networks, graph neural networks, gradient boosting trees, etc. Training 202 may include supervised learning, semi-supervised learning, unsupervised learning, reinforcement learning, and / or the like, including combinations and / or multiples thereof. For example, supervised learning can be used to train a machine learning model from training data with associated labels (i.e., known ground truth) and other data that does not include associated labels. In this example, the training engine 216 takes training queries from the training data 212 as input, makes a join cardinality prediction, and compares the prediction with the known label (i.e., the known join cardinality). The algorithm associated with the trained model then adjusts the weights and / or biases of the model based on the result of the comparison, such as by using backpropagation. Training 202 can be performed multiple times (referred to as an "epoch") until a suitable model (e.g., the trained model 218) is trained. Once trained, the trained model 218 can be used to perform inference 204 to perform a task in order to estimate the join cardinality as previously described. The inference engine 220 applies the trained model 218 to new data 222 (e.g., real-world non-training data). For example, the new data 222 can be a query made during runtime. In short, the new data 222 represents data that the trained model 218 has not been exposed to. The inference engine 220 makes a prediction 224 (e.g., a join cardinality estimate) and passes the prediction 224 to the system 226 (e.g., the computing environment 100 of FIG. 1). The system 226 can take actions that utilize the prediction based on the prediction 224. Such actions can include, for example, generating and / or executing an efficient query execution plan using the predicted join cardinality (e.g., for a database or query optimizer). In some embodiments, the system 226 can add new data 222 and / or modify the new data based on the prediction 224. According to one or more embodiments, the prediction 224 generated by the inference engine 220 is periodically monitored and verified to ensure that the inference engine 220 is operating as expected. Based on the verification, additional training 202 can be performed using the trained model 218 as a starting point. The additional training 202 can include all or a subset of the original training data 212 and / or new training data 212. According to one or more embodiments, training 202 includes updating the trained model 218 to account for changes in the expected input data. Generating and Labeling Training Queries In some embodiments, the training data 212 may be gradually generated from database workloads. In some embodiments, before collecting any workload traces, the join cardinality estimation module 150 may generate one or more synthetic queries (i.e., the training data 212) for the database. These queries include a mix of patterns commonly used in production environments. The characteristics of these patterns may be characterized by the number of joins, the number of joins and local predicates, the type of join (e.g., inner join, outer join, anti-join), the join and local predicate operators (e.g., <, >, >=, <=, =), and the method used to discover joins. In some embodiments, joins may be discovered primarily based on referential integrity constraints that determine the relationship between individual fact tables and dimension tables. If the joins discovered by this method are not sufficient, the join cardinality estimation module 150 may use other methods, including but not limited to data mining, schema relationships (e.g., ontologies), row name similarity, value similarity, and actual query workload mining, to discover additional joins and patterns for training. In some embodiments, the patterns used for query generation may be controlled and fine-tuned based on empirical data (e.g., past experience regarding the characteristics of historical database workloads). Encoding queries using a join graph representation Once the training queries are generated, the queries can be encoded into vectors that can be consumed by a machine learning model (e.g., the trained model 218 via the training engine 216). In some embodiments, these vectors are constructed by using two constructs related to the query join graph: the adjacency matrix and the node coordinates. A query may have multiple query blocks separated by non-join operators (e.g., the UNION or aggregation (GROUP BY) operators). In some embodiments, if the joins within each query block cannot be merged into a single joined query block, those joins are encoded separately. Join characteristics of edges encoded as an adjacency matrix In some embodiments, the adjacency matrix of the join graph is used as a building block to encode information about the joins. For a given query that joins a set of n tables, the adjacency matrix may be defined as an n×n matrix AM n×n , where: As an example, consider the query regarding the example join graph 300 depicted in FIG. 3A, where T N represents the different tables involved in the join. The example adjacency matrix 350 of the join graph 300 may be defined as shown in FIG. 3B. In some embodiments, assuming the connectivity graph is undirected, the adjacency matrix (see Figure 3B) is symmetric. It is observed that one side of the diagonal axis carries as much information as the entire matrix. Some models, such as fully connected neural network models, accept input in the form of a one-dimensional vector. In this case, the adjacency matrix can be compressed into a one-dimensional vector representing one side of the diagonal axis, as depicted in Figure 4. It is observed that an n×n matrix will be compressed in this way into a vector of size [n(n - 1)] / 2. Conversely, for graph neural network models, the input does not have to be represented as a one-dimensional vector, allowing the matrix structure to be retained. All such configurations are within the scope of this disclosure. In some embodiments, in the case of self-connections, a separate reserved position can be used for the second example of the table. For example, when the query is a single self-connection on the table, a 2×2 adjacency matrix can be used to encode the query, where each example of the table occupies one of the two positions. In some embodiments, this general structure description is then used to encode different pieces of information about each connection that are necessary for the model learning outcome cardinality, as discussed in more detail herein. Connection type (JT) In some embodiments, an array is used instead of each element of the adjacency matrix to represent connection types (such as, inner connection, outer connection, and anti-connection), resulting in a three-dimensional matrix JT n×n×m , where n is the number of tables involved, and m is the number of connection types supported by the model plus one. In other words, each position of the n×n matrix (constructed as previously discussed) can be filled with an array of size m that defines a one-hot encoding of the connection type, extended by an additional element (the "plus one") representing the connection order. It should be noted that this last element is necessary because the relative ordering of inner connections with respect to outer or anti-connections can affect the cardinality of the outer or anti-connections. Thus, this can be indicated by a sorting encoding in the last position of the array corresponding to that connection. For example, consider a scenario with the following connection characteristics: (T1 inner connection T2 ON T1.C1 = T2.C1) left outer connection (T3 anti-connection T4 ON T3.C2 = T4.C2) ON T1.C3 = T3.C3. The T1 connection to T2 can be encoded as (1,0,0,1), the T3 anti-connection to T4 can be encoded as (0,0,1,2), and the left outer connection can be encoded as (0,1,0,3). In some embodiments, for example, if a model that requires a one-dimensional vector representing one side of the diagonal axis is used, then this three-dimensional matrix is then compressed into a one-dimensional vector of size [mn(n - 1)] / 2, as previously discussed. An example three-dimensional matrix 500 and its resulting one-dimensional vector 550 are depicted in Figure 5. Connection operator (JO) In some embodiments, each join in a query may involve one or more join predicates that associate different rows on either side of the join. Each join predicate associates a pair of rows using an operator (e.g., <, >, <=, >=, =, LIKE, IN). In some embodiments, the operators are represented by bit vectors. Assuming the model (e.g., trained model 218) supports 7 operators, the corresponding encoding will be a bit vector of size 7, where the value 1 in each position corresponds to the presence of a certain operator in the join. For example, a join with the "<" operator can be represented by [1 0 0 0 0 0 0]. A join with more than one join operator can also be encoded in the same way. For example, a join with "<" and "=" operators can be represented by [1 0 0 0 1 0 0]. Similar to the join type, these bit vectors are stacked in a three-dimensional adjacency matrix JO n×n×k stacked, where k is the number of supported operators. If a model that requires a one-dimensional vector is used, this matrix can be compressed into a one-dimensional vector of size [kn(n - 1)] / 2, as previously discussed. Ratio of join row cardinality to table cardinality (CC) The ratio of the cardinality of the join rows on each side of the join to the table cardinality provides a signal about the uniqueness of the join rows. This value ranges between zero and one, where a value closer to zero indicates a small number of distinct values in the join rows, and a value closer to one indicates unique or nearly unique join rows. This is a contributing factor to the resulting cardinality. Thus, in some embodiments, this information is calculated and collected at compile time and included in the encoding. In one embodiment, the calculations are performed based on statistics available for different tables and rows: table cardinality, row cardinality (COLCARD), and row group cardinality (COMBINED_COLCARD). If a join includes more than one join predicate, where at least on one side of the join, more than one row is involved, then the COMBINED_COLCARD of those rows is used in the numerator. Otherwise, the row cardinality of the single row involved is used. Other methods for calculating the cardinality ratio can also be used, including but not limited to operational sampling, learned models (e.g., trained model 218 and / or another model), or other statistics such as multi-row histograms. In some embodiments, once calculated, the ratios on both sides of the join are encoded using a three-dimensional adjacency matrix CC n×n×2 to encode, which three-dimensional adjacency matrix is then compressed into a one-dimensional vector of size n(n - 1), as previously described. Figure 6 depicts the join rows (T i .A, T j.Examples of the ratio of the row base to the table base in (A) are shown in Table 600 and the resulting one-dimensional vector 650. Ratio of the table base (RC) The ratio of the sizes of the tables on both sides of the connection is another piece of information that can be a significant contributing factor to the resulting base. In some embodiments, this information is calculated and collected at compile time based on the statistics available in the optimizer. The adjacency matrix CR n×n is used to encode the calculated ratio, and the adjacency matrix is then compressed into a one-dimensional vector of size as previously described (e.g., in the case of using a model that requires a one-dimensional vector). Figure 7 depicts an example table 700 of the ratio of the base of the left table to the right table (T i , T j ) encoded using the adjacency matrix and the resulting one-dimensional vector 750. Skewness of the connection row (SK) The values in the connection row after applying the local predicate can exhibit different degrees of skewness. It is expected that the connections on a uniformly distributed connection row will have a different impact on the base compared to connections on a skewed row. In some embodiments, a measure of skewness can be calculated for each connection row after applying the local predicate to a sample of values from the original table. Alternatively, the skewness factor can be learned by a supervised learning model (e.g., the trained model 218 and / or another model). The "Gini coefficient" is a measure that can represent the skewness factor compressed into a single number between zero and one. A value closer to zero indicates perfect equality (uniformity), while a value closer to one indicates perfect inequality or skewness. In some embodiments, when at least one side of the connection involves more than one row, the skewness factor can be calculated for the combined values in the involved rows. Although this measure has been shown to be effective in capturing the skewness factor, other skewness measures can be selected for the encoding pattern. Two values corresponding to the skewness of the connection rows on each side of the connection are encoded into an adjacency matrix SK n×n×2 , and the adjacency matrix is then compressed into a one-dimensional vector of size n(n - 1), as previously discussed. Figure 8 depicts an example table 800 of the skewness factor (i.e., the selectivity of the most common value) on the connection row (T i .A, T j .A) encoded using the adjacency matrix, and depicts the resulting one-dimensional vector 850 if input to the model is required. Connection factor (JF) Some behavior profiles of the join can be captured by calculating the join predicate selectivity from the sample of the table involved (e.g., there is an overload dimension where there are a very large number of dimension row values for very few fact row values, an expansion with many-to-many joins, etc.). This can be referred to as the join factor. In some embodiments, the join factor can be calculated in three steps. First, calculate the join result from the sample (this is "C1"). Next, calculate the Cartesian product based on the sample cardinality on both sides of the join (this is "C2"). Finally, calculate the composite join factor as C1 / C2. In some embodiments, the join factor information is captured offline and stored as part of the database statistics for the join predicate. When a given join has multiple join predicates, the join factor can be captured separately for each join predicate. In some embodiments, the minimum, average, and maximum join factors are calculated for each join. Thus, in some embodiments, each join will have three values of the join factor, which can be captured in a three-dimensional adjacency matrix and then compressed into a one-dimensional vector of size as previously discussed. For convenience, the separate instance table for the join factor is omitted (refer to the instance table and one-dimensional vector of FIG. 8, but consider that each position will have three elements). Include factor (IF) Whether one side of the join is a superset of the other side is a contributing factor to the estimated join cardinality. In some embodiments, the join cardinality estimation module 150 captures this information, called the include factor. In some embodiments, the include factor can be determined in four steps. First, from the sample, capture the number of distinct values of the join rows from either side of the join. Next, calculate the number of values that match between the two sets. Then, calculate the size of the Cartesian product between the two sets. Finally, calculate the ratio of the number of matching values by the size of the Cartesian product to obtain the include factor. In some embodiments, the include factor information is captured offline and stored as part of the database statistics for the join predicate. When a given join has multiple join predicates, the include factor can be captured separately for each join predicate. In some embodiments, the minimum, average, and maximum include factors can be calculated for each join. Thus, each join will have three values of the include factor, which can be captured in a three-dimensional adjacency matrix and then compressed into a one-dimensional vector of size as previously discussed. For convenience, the separate instance table for the include factor is omitted (refer to the instance table and one-dimensional vector of FIG. 8, but consider that each position will have three elements). Node coordinates (NC) Base table cardinality and local predicate selectivity In some embodiments, other characteristics of a query that are attributes of a table rather than attributes of a join can be encoded as node coordinates. Such characteristics include the cardinality of the base table and the selectivity of the local predicates on the base table. In some embodiments, this information is used to predict the resulting cardinality of a join query. Table cardinality can be obtained from statistics that are typically available in a relational database management system (RDBMS). The selectivity of the local predicates can be estimated by applying the local predicates to a sample of the base table, or by any other means (such as histograms or selectivity models) used in an optimizer to estimate the selectivity of the local predicates. FIG. 9 depicts an example node coordinate encoding 900 of table attributes and the resulting one-dimensional vector 950. As shown in FIG. 9, the node coordinates 910 can be represented as a tuple (a, b), where a represents the base table cardinality before applying the local predicate, and b represents the base table cardinality after applying the local predicate. If necessary, the node coordinates 910 can be compressed into a one-dimensional vector of size 2n, as previously discussed. Local predicate correlation It has been observed that when multiple local predicates are applied to a given table, if the composite selectivity is estimated by a model, the model implicitly captures the correlations between the predicate rows. However, if an accurate composite selectivity estimate is not obtained, then in some embodiments, the pairwise correlations can be explicitly captured as part of the encoding. These correlation factors can be captured offline and stored as part of the database statistics. In the presence of multiple predicates, all pairwise correlations are loaded from the statistics and aggregated by taking the minimum, average, and maximum correlations. In some embodiments, these three features are captured as additional node coordinates of the join graph representation. Join graph encoding In some embodiments, the above fragments (e.g., join type (JT), join operator (JO), ratio of join row cardinality to table cardinality (CC), ratio of table cardinality (RC), skewness of join rows (SK), join factor (JF), inclusion factor (IF), and node coordinates (NC)) can be calculated and collected in parallel to reduce the compilation overhead. In some embodiments, the calculation can be done once per query compilation for the entire join graph, since it is independent of the plan choices and transformations evaluated by the production query optimizer during the process of searching for the best query execution plan. In some embodiments, once the different fragments of the encoding (e.g., JT, JO, CC, CR, SK, JF, IF, and NC) are ready as one-dimensional vectors, they can be concatenated together to form the final encoding for the query: Other applications Although the proposed join graph representation is used here to build a join cardinality model, it is not limited to this application in any way. This representation can be used in any model that requires information about a query as input. For example, it can be used in a join plan model where the best join order or the best execution plan must be predicted for a given query. Preprocessing Tags Cardinality tags can have a wide range of values and typically exhibit large skewness. Therefore, a logarithmic transformation is applied to the tags to reduce the skewness and make them a more suitable target for machine learning models to learn. This is performed by the following formula, where represents the transformed tag. The logarithmically transformed tags are closer to a normal distribution. However, the range of values they take is still not suitable for deep learning models that are best at predicting values between zero and one. Therefore, the logarithmic tags are transformed using min-max scaling according to the following equation: and can be obtained from the tags in the training data and stored for future model invocation. Preprocessing Input The input values of the encoded query are also transformed using min-max scaling, so that all input values take a range between zero and one. This is necessary to help the machine learning model converge more quickly. This is performed by the following equation: Here, and are arrays that store the minimum and maximum values of all features in the input training data. In some embodiments, these arrays are collected and stored for future model invocation. Multiple Specialized Models Although a single model can effectively learn to predict the cardinality of different classes of queries, it is also possible to train multiple models that are specialized in a particular class. Query classes are determined by the patterns they exhibit, such as query graph patterns (linear, star, cyclic, etc.), the presence of joining multiple predicates at a time, the presence of self-joins, etc. Queries in each class can exhibit different behaviors and show different resulting cardinality distributions. Each model can thus be specialized to predict the cardinality of a particular class. Specialized models can make more accurate predictions at the cost of a relatively high training overhead. In cases where model training is performed offline and not on the critical path of query execution, the additional overhead can be tolerated in most environments. Model Architecture, Tuning, and Validation Depending on the complexity of the workload and the size of the training dataset, neural networks with various architectures can provide optimal performance. This includes the number of hidden layers (network depth), the number of neurons in each layer (network width), and various combinations of activation functions for the hidden and output layers. Various objective functions can be used to train the model. Mean squared error is an effective objective function for this usage scenario. Although the parameters found to be effective during the development stage are supplied as default configurations, these values can also be automatically tuned at the customer site to adapt to their specific workload characteristics. This can be done by performing a grid search over the combination of parameters to find the combination that minimizes the objective function on the validation set. Additionally, early stopping techniques are used to avoid overfitting. Model Evaluation The accuracy of the model is measured using q-error, which is the de facto standard for measuring the accuracy of cardinality estimates. The q-error is calculated as follows: The accuracy of each model can be measured and compared on the validation set, and models that exceed a certain threshold are activated for use. If the threshold criteria are not met, the results are analyzed to determine which category of queries is affected by suboptimal performance. This will lead to the generation of target queries, which are then used to augment the training data with more queries from those categories. In some embodiments, the model training procedure is repeated until the performance criteria are met. Input for Inference At inference time (e.g., during inference 204), the information required for encoding can be obtained from various sources. The sizes of tables, rows, and row groups can be collected via statistics commonly available in the RDBMS or via external and / or internal modules (e.g., the join cardinality estimation module 150) that periodically monitor and extract statistics. The selectivity of local predicates can be obtained from estimation methods such as selectivity models or histograms available in the optimizer, or from applying the local predicates to a sample of the table, or from a feedback warehouse maintained based on actual run-time. The same applies to calculating or estimating the skewness of joined rows, as previously described. In some embodiments, input preprocessing is performed based on the and arrays collected and stored during the training stage, as previously described. Invoking the Model Depending on which category the query belongs to, the preprocessed input data is fed into the corresponding model, and the target value is calculated. The model is invoked during the query optimization phase of query compilation, during which the optimizer will enumerate various permutations of the join order. For each of these join orders, the optimizer will use the associated encoding for that join order to invoke the model. The optimizer may enumerate different permutations of the join order for the same set (or subset) of joins, but the resulting cardinality for each join order is the same. To minimize any additional overhead of repeatedly constructing the input encoding and / or invoking the model, the prediction results can be calculated once for each join combination and cached for later reuse. Inverse transformation of prediction Since the model predicts a transformed version of the cardinality value, it must be inverse-transformed before it can be used in the optimizer. This inverse transformation consists of two steps: inverse min-max scaling and inverse logarithmic transformation, as follows: Continuous learning from runtime feedback In some embodiments, the performance of the model is continuously measured and monitored for incoming queries. If the prediction accuracy does not meet the performance criteria, the corresponding query is analyzed and the category to which the query belongs is identified. This results in the generation of queries that exhibit the same pattern. The new queries are encoded and added to the training data and used to train future models. Runtime feedback can also help obtain more accurate information, which is encoded to get better predictions from the existing model. Alternative methods for handling various join types Alternatively or additionally, the join cardinality models described previously in this document can be trained using queries that include only inner joins. The predictions from such models can be used to estimate other types of joins. This means that in the representation, the join type encodings described previously will be excluded (since by default, all joins will be inner joins). In some embodiments, the cardinality for left outer join (LOJ), right outer join (ROJ), and full outer join (FOJ) is calculated as follows: First, LOJ = IJ + LAJ; Next, ROJ = IJ + RAJ; Finally, FOJ = IJ + LAJ + RAJ, where LAJ represents the left anti-join and RAJ represents the right anti-join. The anti-join calculation can be performed in multiple ways. The first method is to use the simplifying assumptions made by some current optimizers for calculating such joins. The second method will require the model to predict multiple statistics for a given node. Specifically, the model will predict not only the cardinality of the inner join, but also the filter factor of the inner stream (inner_ff) and the filter factor of the outer stream (outer_ff). These two will allow the LAJ and RAJ to be estimated as follows: First, LAJ = (1 - outer_ff) * cart_card; next, RAJ = (1 - inner_ff) * cart_card, where cart_card represents the cardinality of the Cartesian product of the inner and outer streams. To make this simpler, in some embodiments, the model can be designed to only predict outer_ff. The cardinality of RAJ can then be estimated by using outer_ff to convert RAJ into LAJ in the input. The third method is to build an anti-join model for at least paired base tables with suitable local predicates. Limiting the model to only inner joins has two main benefits: the size of the encoding and thus the model complexity will be reduced, resulting in better accuracy and generalization, and model training becomes relatively cheaper because relatively few data points will be required. Although such methods are expected to give better estimates for inner joins, their accuracy for outer joins and anti-joins depends on the appropriate estimation of inner_ff and outer_ff. Whether to train the model by including all connection types or only using inner joins can be determined on a case-by-case basis, depending on the comparison of the two methods for a given database. Performance Results and Comparison with Previous Models The join cardinality estimation framework described herein (represented using a join graph) is built on previous join cardinality estimation methods, such as (for example) the so-called query graph representation. Advantageously, the architecture of the present invention can be generalized to unseen joins and can be further generalized and extrapolated to more joins (e.g., from 1 to 4 seen joins, extrapolated to 5 or more unseen joins). The join cardinality estimation framework described herein has been found to extrapolate to 14 joins with minimal error (specifically, the log prediction / actual rate is less than 7.5) when trained on combinations of 4 joins, far exceeding previous results. The model of the present invention can outperform previous solutions for estimating join cardinality because the model described herein is specialized for joins, thereby reducing training time, reducing the model size, and reducing the error in join cardinality estimation. In addition, this solution can work together with previous methods based on query graph representation, where the previous architecture can be used for the non-joined parts of the query graph, and the model built according to one or more embodiments described herein can be used to capture the joins and provide the input to the previous models to represent the joins as the derived results input to those models. In general, the connection cardinality estimation framework described herein provides an efficient model that is trained using a relatively small encoding (compared to prior frameworks that are not connection cardinality specific models), resulting in a compact model with fewer parameters. As a result, the size of the model can be much smaller, leading to faster inference (i.e., making predictions). Additionally, since the training time is proportional to the size of the encoding and the complexity of the model (model parameters), the smaller encoding provided to the models built as described herein in combination with a simpler model directly translates to a significantly (several orders of magnitude) faster training scenario. Now referring to FIG. 10, there is generally shown a flowchart 1000 for providing learned connection cardinality estimation using a connection graph representation according to an embodiment. Flowchart 1000 is described with reference to FIGS. 1 - 9 and may include additional blocks not depicted in FIG. 10. Although depicted in a particular order, the blocks depicted in FIG. 10 may be reconfigured, subdivided, and / or combined. In an illustrative embodiment, method 1000 may be performed by a computing environment (e.g., computing environment 100 shown in FIG. 1). The method includes steps for building a connection cardinality estimation model. At block 1002, the method includes generating training queries with known connection cardinalities. At block 1004, the method includes generating an adjacency matrix of the connection graph encoding the training queries. At block 1006, the method includes compressing the adjacency matrix into a one - dimensional vector on one side of the diagonal axis of the encoded adjacency matrix. At block 1008, the method includes training the model using the one - dimensional vector (if suitable for the connection cardinality estimation model) and the known connection cardinalities. At block 1010, the method includes performing inference using the connection cardinality estimation model. The inference includes a predicted connection cardinality for the query. At block 1012, the method includes performing a query execution plan for the query using the predicted connection cardinality. Now referring to FIG. 11, there is generally shown a flowchart 1100 for training a connection cardinality estimation model according to an embodiment. Flowchart 1100 is described with reference to FIGS. 1 - 9 and may include additional blocks not depicted in FIG. 11. Although depicted in a particular order, the blocks depicted in FIG. 11 may be reconfigured, subdivided, and / or combined. In an illustrative embodiment, method 1100 may be performed by a computing environment (e.g., computing environment 100 shown in FIG. 1). At block 1102, the method includes generating training queries with known connection cardinalities. At block 1104, the method includes generating an adjacency matrix of the connection graph encoding the training queries. At block 1106, the method includes compressing the adjacency matrix into a one - dimensional vector on one side of the diagonal axis of the encoded adjacency matrix. At block 1108, the method includes training the model using the one - dimensional vector (if suitable for the connection cardinality estimation model) and the known connection cardinalities. Referring now to FIG. 12, there is generally shown a flowchart 1200 for performing inference using a connection cardinality estimation model according to an embodiment. Flowchart 1200 is described with reference to FIGS. 1-9 and may include additional blocks not depicted in FIG. 12. Although depicted in a particular order, the blocks depicted in FIG. 12 may be reconfigured, subdivided, and / or combined. In an exemplary embodiment, method 1200 may be performed by a computing environment (e.g., computing environment 100 shown in FIG. 1). At block 1202, the method includes performing inference using a trained connection cardinality estimation model. The inference includes a predicted connection cardinality for the query. At block 1204, the method includes generating an adjacency matrix of a connection graph encoding the query. At block 1206, the method includes: compressing the adjacency matrix into a one-dimensional vector (if suitable for the model), encoding one side of the diagonal axis of the adjacency matrix. At block 1208, the method includes inputting the encoded connection graph into the connection cardinality estimation model. At block 1210, the method includes receiving the predicted connection cardinality as an output. At block 1212, the method includes performing a query execution plan for the query using the predicted connection cardinality. Various embodiments of the present invention are described herein with reference to the related drawings. Alternative embodiments may be designed without departing from the scope of the present invention. It should be noted that various connection and positional relationships (e.g., above, below, adjacent, etc.) are set forth in the following description and between the elements in the drawings. Unless otherwise specified, these connection and / or positional relationships may be direct or indirect, and the present invention is not intended to be limited in this regard. Accordingly, the coupling of entities may refer to direct or indirect coupling, and the positional relationship between entities may be direct or indirect positional relationship. In addition, the various tasks and program steps described herein may be incorporated into a more comprehensive process or program having additional steps or functionality not described in detail herein. One or more of the methods described herein may be implemented using any one or combination of the following techniques, each of which is well known in the art: one (or more) discrete logic circuits having logic gates for implementing logic functions after data signals; application specific integrated circuits (ASICs) having appropriate combinations of logic gates; one (or more) programmable gate arrays (PGAs); a field programmable gate array (FPGA), etc. For the sake of brevity, conventional techniques related to practicing and using aspects of the present invention may or may not be described in detail herein. In particular, various aspects of the computing systems and specific computer programs for implementing the various technical features described herein are well known. Accordingly, for the sake of brevity, many conventional implementation details are only briefly mentioned herein or omitted entirely without providing well-known system and / or program details. In some embodiments, various functions or operations may occur at a given location and / or in conjunction with the operation of one or more devices or systems. In some embodiments, a portion of a given function or operation may be performed at a first device or location, and the remainder of the function or operation may be performed at one or more additional devices or locations. The terminology used herein is for the purpose of describing particular embodiments only and is not intended to be limiting. As used herein, unless the context clearly indicates otherwise, the singular forms "a / an" and "the" are intended to include the plural forms as well. It should be further understood that the terms "comprises and / or comprising," when used in this specification, specify the presence of the stated features, integers, steps, operations, elements, and / or components, but do not preclude the presence or addition of one or more other features, integers, steps, operations, elements, components, and / or groups thereof. All structural, material, acts, and equivalents of the corresponding structures, materials, acts, and step-plus-function elements in the following claims are intended to include any structure, material, or act for performing the function in combination with other claimed elements for a particular claim. The present disclosure has been presented for purposes of illustration and description, but is not intended to be exhaustive or limited to the disclosed forms. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the present disclosure. The embodiments were chosen and described in order to best explain the principles of the present disclosure and its practical application, and to enable others of ordinary skill in the art to understand the present disclosure with various embodiments having various modifications suited to the particular use contemplated. The drawings depicted herein are illustrative. There may be many variations to the drawings or the steps (or operations) described therein without departing from the spirit of the present disclosure. For example, the acts may be performed in a different order or acts may be added, deleted, or modified. Additionally, the term "coupled" describes having a signal path between two elements and does not imply a direct connection between the elements without intervening elements / connections therebetween. All such variations are considered to be a part of the present disclosure. The following definitions and abbreviations will be used to interpret the claims and the specification. As used herein, the terms "comprises / comprising," "includes / including," "has / having," "contains or containing," or any other variation thereof are intended to cover a non-exclusive inclusion. For example, a composition, mixture, process, method, article, or apparatus that comprises a list of elements is not necessarily limited to those elements, but may include other elements not expressly listed or inherent to such composition, mixture, process, method, article, or apparatus. Additionally, the term "exemplary" is used herein to mean "serving as an example, instance, or illustration". Any embodiment or design described herein as "exemplary" is not necessarily to be construed as preferred or advantageous over other embodiments or designs. The terms "at least one" and "one or more" are understood to include any integer greater than or equal to one, i.e., one, two, three, four, etc. The term "a plurality of" is understood to include any integer greater than or equal to two, i.e., two, three, four, five, etc. The term "connected" may include both indirect "connection" and direct "connection". The terms "about", "substantially", "approximately" and variations thereof are intended to include the degree of error associated with a particular quantity of measurement based on the equipment available at the time of filing the present application. For example, "about" may include a range of ±8% or ±5% or ±2% of a given value. The present invention may be a system, method, and / or computer program product at any possible technical detail integration level. The computer program product may include one (or more) computer-readable storage media having computer-readable program instructions thereon to cause a processor to perform aspects of the present invention. The computer-readable program instructions described herein may be downloaded from a computer-readable storage media to a respective computing / processing device or downloaded to an external computer or an external storage device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network). The network may include copper transmission cables, optical transmission fibers, wireless transmission, routers, firewalls, switches, gateway computers, and / or edge servers. A network interface card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage media within the respective computing / processing device. The computer-readable program instructions for performing the operations of the present invention may be assembly program instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data of an integrated circuit system, or source code or object code written in any combination of one or more programming languages, the one or more programming languages including object-oriented programming languages such as Smalltalk, C++, or the like, and procedural programming languages such as the "C" programming language or similar programming languages. The computer-readable program instructions may be executed entirely on the user's computer, partially on the user's computer, executed as a stand-alone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network connection including a local area network (LAN) or a wide area network (WAN), or may be connected to an external computer (e.g., using an Internet service provider through the Internet). In some embodiments, an electronic circuit system including, for example, a programmable logic circuit system, a field programmable gate array (FPGA), or a programmable logic array (PLA) may execute the computer-readable program instructions by personalizing the electronic circuit system by utilizing the status information of the computer-readable program instructions so as to perform aspects of the present invention. Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block in the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions. These computer-readable program instructions may be provided to a processor of a general purpose computer, a special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions executed via the processor of the computer or other programmable data processing apparatus create means for implementing the functions / acts specified in one or more of the flowchart illustrations and / or block diagrams. These computer-readable program instructions may also be stored in a computer-readable storage medium that can direct a computer, a programmable data processing apparatus, and / or other devices to function in a particular manner, such that the computer-readable storage medium storing the instructions contains an article of manufacture including instructions implementing aspects of the functions / acts specified in one or more of the flowchart illustrations and / or block diagrams. The computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other devices to produce a computer-implemented procedure, such that the instructions executed on the computer, other programmable apparatus, or other devices implement the functions / acts specified in one or more of the flowchart illustrations and / or block diagrams. The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in the flowchart or block diagram may represent a module, segment, or portion of instructions that include one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may, in fact, be executed substantially concurrently, or the blocks may sometimes be executed in reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, can be implemented by a special-purpose hardware-based system that performs the specified functions or acts or combinations of special-purpose hardware and computer instructions. The description of the various embodiments of the present invention has been presented for purposes of illustration, but is not intended to be exhaustive or limited to the embodiments disclosed. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terms used herein have been chosen to best explain the principles of the embodiments, the practical application, or technical improvement of technologies found in the marketplace, or to enable others of ordinary skill in the art to understand the embodiments described herein. 100: Computing Environment 101: Computer 102: Wide Area Network (WAN) 103: End User Device (EUD) 104: Remote Server 105: Public Cloud 106: Private Cloud 110: Processor Group 111: Communication Mesh 112: Volatile Memory 113: Persistent Storage 114: Peripheral Device Group 115: Network Module 120: Processing Circuitry 121: Cache Memory 122: Operating System 123: User Interface (UI) Device Group 124: Storage 125: Internet of Things (IoT) Sensor Group 130: Remote Database 140: Gateway 141: Cloud Orchestration Module 142: Host Physical Machine Group 143: Virtual Machine Group 144: Container Group 150: Connection Cardinality Estimation Module / Block 202: Training 204: Inference 212: Training Data 214: Untrained Model 216: Training Engine 218: Trained Model 220: Inference Engine 222: New Data 224: Prediction 226: System 300: Connection Graph 350: Adjacency Matrix 500: Three - Dimensional Matrix 550: One - Dimensional Vector 600: Table 650: One - Dimensional Vector 700: Table 750: One - Dimensional Vector 800: Table 850: One - Dimensional Vector 900: Node Coordinate Encoding 910: Node Coordinates 950: One - Dimensional Vector 1000: Flowchart / Method 1002: Block 1004: Block 1006: Block 1008: Block 1010: Block 1012: Block 1100: Flowchart / Method 1102: Block 1104: Block 1106: Block 1108: Block 1200: Flowchart / Method 1202: Block 1204: Block 1206: Block 1208: Block 1210: Block 1212: Block The details of the exclusive rights described herein are particularly pointed out and distinctly claimed in the claims at the end of this specification. The foregoing and other features and advantages of embodiments of the invention will be apparent from the following detailed description taken in conjunction with the accompanying drawings, in which: FIG. 1 depicts a block diagram of an example computing environment for use in conjunction with one or more embodiments; FIG. 2 depicts a block diagram of a system for training and using a machine learning model for connection cardinality estimation based on a connection graph representation according to one or more embodiments; FIG. 3A depicts an example connection graph according to one or more embodiments; FIG. 3B depicts an example adjacency matrix for the connection graph of FIG. 3A according to one or more embodiments; FIG. 4 depicts an example encoding of an adjacency matrix to a one - dimensional vector according to one or more embodiments; Figure 5 depicts an example three-dimensional matrix and its resulting one-dimensional vector according to one or more embodiments; Figure 6 depicts an example table of the ratio of the row cardinality to the table cardinality of a concatenated row encoded according to one or more embodiments; Figure 7 depicts an example table of the ratio of the cardinality of the left table to the cardinality of the right table of a concatenation encoded according to one or more embodiments; Figure 8 depicts an example table of the skewness factor on a concatenated row encoded according to one or more embodiments; Figure 9 depicts an example node coordinate encoding of the table attributes of a concatenation and its resulting one-dimensional vector according to one or more embodiments; Figure 10 is a flowchart according to one or more embodiments of the present invention; Figure 11 is a flowchart according to one or more embodiments of the present invention; and Figure 12 is a flowchart according to one or more embodiments of the present invention. The diagrams depicted herein are illustrative. Many variations to the described diagrams or operations are possible without departing from the spirit of the invention. For example, actions may be performed in a different order or actions may be added, deleted, or modified. In the accompanying drawings and the following detailed description of the described embodiments of the invention, various elements depicted in the figures have two or three-digit element symbols. With few exceptions, the leftmost digit of each element symbol corresponds to the figure in which its element is first depicted. 1000: Flowchart / Method 1002: Block 1004: Block 1006: Block 1008: Block 1010: Block 1012: Block

Claims

1. A computer-implemented method comprising: constructing a join cardinality estimation model by: generating a training query having a known join cardinality; generating an adjacency matrix encoding a join graph of the training query, wherein for a given query joining a set of n tables, each adjacency matrix can be defined as an n×n matrix, wherein a value of 1 is given at a position (i, j) if table i is joined with table j, and 0 otherwise; encoding one side of a diagonal axis of the adjacency matrix; and training the join cardinality estimation model using the encoded adjacency matrix and the known join cardinality; performing an inference using the join cardinality estimation model, the inference including a predicted join cardinality for a query; and performing a query execution plan for the query using the predicted join cardinality.

2. The computer implementation method of claim 1, wherein performing the inference includes: generating an adjacency matrix of a connectivity graph encoding the query; encoding one side of a diagonal axis of the adjacency matrix; inputting the encoded adjacency matrix into the connectivity cardinality estimation model; and receiving the predicted connectivity cardinality as output.

3. The computer implementation method of claim 2, wherein encoding the adjacency matrix includes compressing the adjacency matrix into a one-dimensional vector for use in machine learning algorithms that require a vector input.

4. The computer implementation method of claim 1, wherein building the connectivity cardinality estimation model further comprises: generating an additional adjacency matrix encoding one of the connectivity types of the training query; encoding one side of one diagonal axis of the additional adjacency matrix into a connectivity type adjacency matrix; and concatenating the encoded connectivity type adjacency matrix with the encoded connectivity graph before training the connectivity cardinality estimation model.

5. The computer implementation method of claim 1, wherein building the connectivity cardinality estimation model further comprises: generating an additional adjacency matrix encoding a connectivity operator of the training query; encoding one side of the diagonal axis of the additional adjacency matrix into a connectivity operator adjacency matrix; and concatenating the encoded connectivity operator adjacency matrix with the encoded connectivity graph before training the connectivity cardinality estimation model.

6. The computer implementation method of claim 1, wherein building the connection cardinality estimation model further comprises: generating an additional adjacency matrix that encodes a ratio of the cardinality of the connected rows to the table cardinality on each side of a connection in the training query; encoding one side of a diagonal axis of the additional adjacency matrix into a row-to-table adjacency matrix; and concatenating the encoded row-to-table adjacency matrix with the encoded connection graph before training the connection cardinality estimation model.

7. The computer implementation method of claim 1, wherein building the connection cardinality estimation model further comprises: generating an additional adjacency matrix that encodes a ratio of the cardinality of the left and right tables of a connection of the training query; encoding one side of a diagonal axis of the additional adjacency matrix into a table cardinality adjacency matrix; and concatenating the encoded table cardinality adjacency matrix with the encoded connection graph before training the connection cardinality estimation model.

8. The computer implementation method of claim 1, wherein building the connectivity cardinality estimation model further comprises: generating an additional adjacency matrix that encodes a measure of skewness for each row of a connection for the training query; encoding one side of a diagonal axis of the additional adjacency matrix into a skewness adjacency matrix; and concatenating the encoded skewness adjacency matrix with the encoded connectivity graph before training the connectivity cardinality estimation model.

9. The computer implementation method of claim 1, wherein building the connectivity cardinality estimation model further comprises: generating an additional adjacency matrix that encodes a measure of connectivity selectivity of a connection of the training query that does not have a local predicate; encoding one side of a diagonal axis of the additional adjacency matrix into a connectivity factor adjacency matrix; and concatenating the encoded connectivity factor adjacency matrix with the encoded connectivity graph before training the connectivity cardinality estimation model.

10. The computer implementation method of claim 1, wherein building the connectivity cardinality estimation model further comprises: generating an additional adjacency matrix that encodes a measure of inclusion on the other side of a value of a join row of the training query; encoding one side of a diagonal axis of the additional adjacency matrix into a factored adjacency matrix; and concatenating the encoded factored adjacency matrix with the encoded connectivity graph before training the connectivity cardinality estimation model.

11. The computer implementation method of claim 1, wherein building the connectivity cardinality estimation model further comprises: generating an additional adjacency matrix that encodes a cardinality of a particular base table for a connection of the training query and a selectivity of local predicates on the base tables; encoding one side of a diagonal axis of the additional adjacency matrix into a node coordinate adjacency matrix; and concatenating the encoded node coordinate adjacency matrix with the encoded connectivity graph before training the connectivity cardinality estimation model.

12. A computer system having a memory, computer-readable instructions, and one or more processors for executing the computer-readable instructions, the computer-readable instructions controlling the one or more processors to perform operations including: constructing a connection cardinality estimation model by: generating a training query having a known connection cardinality; generating an adjacency matrix encoding a connection graph of the training query, wherein for a given query connecting a set of n tables, each adjacency matrix can be defined as an n×n matrix, wherein if table i is connected to table j, a value of 1 is obtained at a position (i, j), otherwise 0; encoding one side of a diagonal axis of the adjacency matrix; and training the connection cardinality estimation model using the encoded adjacency matrix and the known connection cardinality; performing an inference using the connection cardinality estimation model, the inference including a predicted connection cardinality for a query; and performing a query execution plan for the query using the predicted connection cardinality.

13. The system of claim 12, wherein performing the inference comprises: generating an adjacency matrix of a connectivity graph encoding the query; encoding one side of a diagonal axis of the adjacency matrix; inputting the encoded adjacency matrix into the connectivity cardinality estimation model; and receiving the predicted connectivity cardinality as output.

14. The system of claim 13, wherein encoding the adjacency matrix includes compressing the adjacency matrix into a one-dimensional vector for use in machine learning algorithms that require a vector input.

15. The system of claim 12, wherein building the connectivity cardinality estimation model further comprises: generating an additional adjacency matrix encoding one of the connectivity types of the training query; encoding one side of one diagonal axis of the additional adjacency matrix into a connectivity type adjacency matrix; and concatenating the encoded connectivity type adjacency matrix with the encoded connectivity graph before training the connectivity cardinality estimation model.

16. A computer program product comprising a computer-readable storage medium having program instructions embodied therein, the program instructions being executable by one or more processors to cause the one or more processors to perform operations comprising: constructing a connection cardinality estimation model by: generating a training query having a known connection cardinality; generating an adjacency matrix encoding a connection graph of the training query, wherein for a given query connecting a set of n tables, each adjacency matrix can be defined as an n×n matrix, wherein if table i is connected to table j, a value of 1 is obtained at a position (i, j) in the matrix, and 0 is obtained otherwise; encoding one side of a diagonal axis of the adjacency matrix; and training the connection cardinality estimation model using the encoded adjacency matrix and the known connection cardinality; performing an inference using the connection cardinality estimation model, the inference including a predicted connection cardinality for a query; and performing a query execution plan for the query using the predicted connection cardinality.

17. The computer program product of claim 16, wherein performing the inference includes: generating an adjacency matrix of a connectivity graph encoding the query; encoding one side of a diagonal axis of the adjacency matrix; inputting the encoded adjacency matrix into the connectivity cardinality estimation model; and receiving the predicted connectivity cardinality as output.

18. The computer program product of claim 16, wherein encoding the adjacency matrix includes compressing the adjacency matrix into a one-dimensional vector for use in machine learning algorithms that require a vector input.

19. The computer program product of claim 16, wherein building the connectivity cardinality estimation model further comprises: generating an additional adjacency matrix encoding one of the connectivity types of the training query; encoding one side of one diagonal axis of the additional adjacency matrix into a connectivity type adjacency matrix; and concatenating the encoded connectivity type adjacency matrix with the encoded connectivity graph before training the connectivity cardinality estimation model.

20. A computer-implemented method comprising: generating a training query having a known connection cardinality; generating an adjacency matrix encoding a connection graph of the training query, wherein for a given query connecting a set of n tables, each adjacency matrix can be defined as an n×n matrix, wherein a value of 1 is given at a position (i, j) in the matrix if table i is connected to table j, and 0 otherwise; encoding one side of a diagonal axis of the adjacency matrix; and training the connection cardinality estimation model using the encoded adjacency matrix and the known connection cardinality.

21. The computer implementation method of claim 20, wherein encoding the adjacency matrix includes compressing the adjacency matrix into a one-dimensional vector for use in machine learning algorithms that require a vector input.

22. A computer-implemented method comprising: performing inference using a trained connectivity cardinality estimation model, the inference including a predicted connectivity cardinality for a query, wherein performing the inference comprises: generating an adjacency matrix encoding a connectivity graph of the query, wherein for a given query connecting a set of n tables, each adjacency matrix can be defined as an n×n matrix, wherein a value of 1 is given at a position (i, j) in the matrix if table i is connected to table j, and 0 otherwise; encoding one side of a diagonal axis of the adjacency matrix; inputting the encoded adjacency matrix into the connectivity cardinality estimation model; receiving the predicted connectivity cardinality as output; and using the predicted connectivity cardinality to execute a query execution plan for the query.

Images