US20150186461A1

US20150186461A1 - Cardinality Estimation Using Spanning Trees

Info

Publication number: US20150186461A1
Application number: US14/145,777
Authority: US
Inventors: Anisoar NICA
Original assignee: Sybase Inc
Current assignee: Sybase Inc
Priority date: 2013-12-31
Filing date: 2013-12-31
Publication date: 2015-07-02
Also published as: US9922088B2

Abstract

A system, computer-implemented method, and computer-program product embodiments for determining a cardinality estimate for a query. A cardinality estimator identifies a predicate in a query, where the predicate is split into a plurality of equivalence classes. The cardinality estimator then generates a plurality of equivalence graphs from the plurality of equivalence classes, one equivalence graph for an equivalence class. Spanning trees are identified from the plurality of equivalence graphs, and the cardinality estimator then determines the cardinality estimate for the query from the spanning trees.

Description

BACKGROUND

1. Field
The embodiments relate generally to databases and more specifically to query optimization using cardinality estimation.
2. Background
Computer databases have become a prevalent means for data storage and retrieval. A database user will commonly access the underlying data in a database using a Database Management System (“DBMS”). A user issues a query to the DBMS that conforms to a defined query language. When a DBMS receives a query, it determines a query plan for the query. Once determined, the DBMS then uses the query plan to execute the query. As part of determining an efficient query plan, a DBMS relies on cardinality estimates that estimate the sizes (i.e., how many rows) of queries and sub-queries. Cardinality estimates are used to assess the efficiency (e.g., cost) of the query plan before the query plan is executed.

BRIEF DESCRIPTION OF THE DRAWINGS/FIGURES

The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate embodiments and, together with the description, further serve to explain the principles of the embodiments and to enable a person skilled in the relevant art to make and use the embodiments.

FIG. 1 is an example database computing environment in which embodiments can be implemented.

FIG. 2 is a block diagram of a cardinality estimator, according to an embodiment.

FIGS. 3A-B are diagrams of a forest of graphs corresponding to the join equivalence classes for a query and the minimum spanning trees in the forest of graphs, according to an embodiment.

FIG. 4 is a flowchart of a method for generating a cardinality estimate for a query, according to an embodiment.

FIG. 5 is a flowchart of a method for generating a cardinality estimate for a sub-query, according to an embodiment.

FIG. 6 is a diagram of an algorithm for computing the cardinality of a query, according to an embodiment.

FIG. 7 is diagram of an algorithm for determining join equivalence classes for a query, according to an embodiment.

FIG. 8 is a diagram of an algorithm for computing a selectivity estimate for using spanning trees for a query, according to an embodiment.

FIG. 9 is a diagram of an algorithm for computing the selectivity estimate for using spanning trees for a sub-query, according to an embodiment.

FIG. 10 is a diagram of an algorithm for computing the minimum spanning trees for a graph forest of join equivalence classes, according to an embodiment.

FIG. 11 is a block diagram of an example computer system in which embodiments may be implemented.

DETAILED DESCRIPTION

Provided herein are system, method and/or computer program product embodiments, and/or combinations and sub-combinations thereof, for generating cardinality estimates, where cardinality estimates are used for generating an optimal query plan for a query.
FIG. 1 is an example database computing environment 100 in which embodiments can be implemented. Computing environment 100 includes a database management system (DBMS) 140 and client 110 that communicates DBMS 140. DBMS 140 may be a system executing on a server and accessible to client 110 over a network, such as network 120, described below. Although client 110 is represented in FIG. 1 as a separate physical machine from DBMS 140, this is presented by way of example, and not limitation. In an additional embodiment, client 110 occupies the same physical system as DBMS 140. In a further embodiment, client 110 is a software application which requires access to DBMS 140. In another embodiment, a user may operate client 110 to request access to DBMS 140. Throughout this specification, the terms client and user will be used interchangeably to refer to any hardware, software, or human requestor, such as client 110, accessing DBMS 140 either manually or automatically. Additionally, both client 110 and DBMS 140 may execute within a computer system, such as an example computer system discussed in FIG. 11.
Client 110 and DBMS 140 may communicate over network 120. Network 120 may be any network or combination of networks that can carry data communications. Such a network 120 may include, but is not limited to, a local area network, metropolitan area network, and/or wide area network that include the Internet.
DBMS 140 receives a query, such as query 102, from client 110. Query 102 is used to request, modify, append, or otherwise manipulate or access data in database storage 150. Query 102 is transmitted to DBMS 140 by client 110 using syntax which conforms to a query language. In a non-limiting embodiment, the query language is a Structured Query Language (“SQL”), but may be another query language. DBMS 140 is able to interpret query 102 in accordance with the query language and, based on the interpretation, generate requests to database storage 150.
Query 102 may be generated by a user using client 110 or by an application executing on client 110. Upon receipt, DBMS 140 begins to process query 102. Once processed, the result of the processed query is transmitted to client 110 as query result 104.
To process query 102, DBMS 140 includes a parser 162, a normalizer 164, a compiler 166, and an execution unit 168.
Parser 162 parses the received queries 102. In an embodiment, parser 162 may convert query 102 into a binary tree data structure which represents the format of query 102. In other embodiments, other types of data structures may be used.
When parsing is complete, parser 162 passes the parsed query to a normalizer 164. Normalizer 164 normalizes the parsed query. For example, normalizer 164 eliminates redundant SQL constructs from the parsed query. Normalizer 164 also performs error checking on the parsed query that confirms that the names of the tables in the parsed query conform to the names of tables 180. Normalizer 164 also confirms that relationships among tables 180, as described by the parsed query, are valid.
Once normalization is complete, normalizer 164 passes the normalized query to compiler 166. Compiler 166 compiles the normalized query into machine-readable format. The compilation process determines how query 102 is executed by DBMS 140. To ensure that query 102 is executed efficiently, compiler 166 uses a query optimizer 170 to generate an access plan for executing the query.
Query optimizer 170 analyzes the query and determines a query plan for executing the query. The query plan retrieves and manipulates information in the database storage 150 in accordance with the query semantics. This may include choosing the access method for each table accessed, choosing the order in which to perform a join operation on the tables, and choosing the join method to be used in each join operation. As there may be multiple strategies for executing a given query using combinations of these operations, query optimizer 170 generates and evaluates a number of strategies from which to select the best strategy to execute the query.
In an embodiment, query optimizer 170 generates multiple query plans. Once generated, query optimizer 170 selects a query plan from the multiple query plans to execute the query. The selected query plan may be a cost efficient plan, a query plan that uses the least amount of memory in DBMS 140, a query plan that executes the quickest, or any combination of the above, to give a few examples.
In one embodiment, in order for query optimizer 170 to generate and select a query plan, DBMS 140 uses cardinality estimator 172. Cardinality estimator 172 generates an estimate of the size (i.e., number of rows) of a query plan before the query plan is executed. Based on cardinality estimates, query optimizer 170 costs and selects an efficient query plan that executes query 102 from multiple query plans.
FIG. 2 is a block diagram 200 of a cardinality estimator, according to an embodiment. In block diagram 200, cardinality estimator receives query 102 as input and generates a cardinality estimate 204 as output.
Query 102, such as query Q accesses data in one or more tables. The one or more tables that are accessed using query Q may be represented as tables R_i, i=0 . . . n. In an embodiment, query Q that accesses tables R_imay be presented as:
Q=σ _p(R ₁
. . .
R _n)
In an embodiment, each table R has a set of attributes, denoted as attr(R). The list of attributes on a table R, may be represented as R[A], where the set of attributes A⊂ attr (R), A={A₁, A₂, . . . , A_n}.
In an embodiment, R[A₁, A₂, . . . , A_n] is a subset of attributes of table R, such as A={A₁, . . . , A_n}⊂attr(R).
In an embodiment, query 102 also contains a predicate. A predicate is a condition that may be evaluated in query 102. In an embodiment, a predicate may be a join predicate. A join predicate is a predicate that specifies a join operation that links several tables together or a particular set of attributes when evaluated. An evaluated join predicate, typically returns a join table as a result. For example, a join predicate on tables T and S may be represented as equijoin predicates T[A]=S[A] where A={A₁, . . . , . A_n} are attributes based on which tables T and S are joined, such that A⊂attr (T) and A⊂attr (S). A short form for the join predicate T[A] S[A] may be represented as the conjunct predicate
̂_{kε{1, . . . ,n}},(T[A _k ]=S[A _k])
In an embodiment, to determine a cardinality estimate 204 for query 102, cardinality estimator 172 determines a cardinality estimate over join equivalence classes for a join predicate. A join equivalence class for a predicate may be non-constant or constant. A non-constant join equivalence class ε(p) for a join predicate p=A, ̂_{i,jε{1, . . . m},i≠j}(R_i[A]=R_j[A]) is defined as a set of attribute subsets participating in the join predicate ε(p)=({R₁[A], . . . R_m[A]}), where A={A₁, . . . , A_n} is a set of common attributes for tables R_i, iε{1, . . . , m}.
A constant join equivalence class cε(p) for a join predicate p=(̂_{i,jε{1, . . . , m},i≠j}(R_i[A]=R_j[A]))̂(̂_{iε{1, . . . m},kε{1, . . . , n}}(R_i[A_k]=c_k)) is defined as a tuple of a set of attribute subsets and a constant vector, such that cε(p)=({R₁[A], . . . , R_m[A]}, (c₁, . . . , c_n)) where A={A₁, . . . , A_n} is a set of common attributes for tables R_i, iε{1, . . . , m}. A person skilled in the art will appreciate that a tuple is an ordered set of elements, which is here an ordered set of a subset of attributes and a constant vector.
In an embodiment, cardinality estimator 172 may determine a cardinality estimate over a set of join equivalence classes. For example, given a set of join equivalence classes corresponding to the logical expression:
σ_{p(R1, . . . ,Rm)}(R ₁
R ₂
. . .
R _m)
cardinality estimator 172 computes the cardinality estimation for a sub-expression involving relations {R_i1, . . . R_it}⊂{R₁, . . . , R_m}:
σ_{p′(Ri1, . . . ,Rit)}(R ₁
R ₂
. . .
R _it)
where the predicate p′(R_i1, . . . . R_it) contains all conjuncts of the original predicate p(R₁, . . . , R_m) which refer exclusively to the tables (R_i1, . . . R_it).
In an embodiment, to determine cardinality estimate 204 over a set of join equivalence classes, cardinality estimator 172 generates one or more undirected graphs. From the one or more undirected graphs, cardinality estimator 172 identifies minimum spanning tees that link the vertices of the undirected graph. A person skilled in the art will appreciate that a spanning tree of an undirected graph is a tree that connects all vertices in the undirected graph. Additionally, an edge in the undirected graph has assigned a weight which in the graphs corresponding to the join equivalence classes may represent the quality of the selectivity estimation of an edge.
To build an undirected graph G={V, E}, cardinality estimator 172 determines a set of vertices V (or nodes), where each node R_i[A] represents a relation and the relation's attributes that are participating in the join equivalence class. In an embodiment, for a constant join equivalence class, cardinality estimator 172 generates an extra node for the constant vector (c₁, . . . c_n) as discussed below. In an embodiment, cardinality estimator 172 also generates a set of edges E of the form (R_i, R_j, (p₁, . . . , p_n)), for each join predicate (p₁, . . . , p_n) between R_iand R_jIn an embodiment, cardinality estimator 172 annotates each edge with one or more predicates that correspond to the join predicates between the two nodes of the edge.
To build an undirected graph for a constant join equivalence class cε(p)=({R₁[A], . . . , R_m[A]}, (c₁, . . . , c_n)), cardinality estimator 172 defines the graph of cε(p) as G(cε(p))={V, E}, where V is a set of vertices and E is a set of edges connecting the vertices. In an embodiment the set of vertices V are:
V={R ₁ [A], . . . ,R _m [A],(c ₁ , . . . ,c _n)}
and the set of edges E, are:
E={(R _i [A],R _j [A],(R _i [A ₁ ]=R _j [A ₁ ], . . . ,R _i [An]=R _j [An]))|i,jε{1, . . . m}}∪{(R _i [A],(c ₁ , . . . ,c _n),(R _i [A ₁ ]=c ₁ , . . . ,R _i [A _n ]=c _n))|iε{1, . . . ,m}}
To build an undirected graph for a non-constant join equivalence class ε(p)=({R₁[A], . . . , R_m[A]}), cardinality estimator 172 defines the graph of ε(p) as G(ε(p))={V, E}, where V is a set of vertices and E is a set of edges connecting the vertices. In an embodiment the set of vertices V are:
V={R ₁ [A], . . . ,R _m [A]}
And the set of edges E are:
E={(R _i [A],Rj[A],(R _i [A ₁ ]=R _j [A ₁ ], . . . ,R _i [A _n ]=R _j [A _n]))∥i,jε{1, . . . m}}.
FIG. 3 A is an example graph generated using a cardinality estimator, according to an embodiment. In FIG. 3A, DBMS 140 receives query Q, such that:
Q=σ _p(R ₁
R ₂
R ₃
R ₄
R ₅)
and where the predicate p includes multiple join predicates p1 to p21 at shown below:
$p = \underset{\underset{p 1}{}}{(R 5 [A] = cA} ⋀ \underset{\underset{p 2}{}}{R 5 [B] = cB} ⋀ \underset{\underset{p 3}{}}{R 1 [A] = R 5 [A]} ⋀ \underset{\underset{p 4}{}}{R 1 [B] = R 5 [B]} ⋀ \underset{\underset{p 5}{}}{R 4 [A] = cA} ⋀ \underset{\underset{p 6}{}}{R 4 [B] = cB} ⋀ \underset{\underset{p 7}{}}{R 1 [A] = cA} ⋀ \underset{\underset{p 8}{}}{R 1 [B] = cB} ⋀ \underset{\underset{p 9}{}}{R 1 [A] = R 4 [A]} ⋀ \underset{\underset{p 10}{}}{R 1 [B] = R 4 [B]} ⋀ \underset{\underset{p 11}{}}{R 4 [A] = R 5 [A]} ⋀ \underset{\underset{p 12}{}}{R 4 [B] = R 5 [B]} ⋀ \underset{\underset{p 13}{}}{R 1 [A] = R 3 [A]} ⋀ \underset{\underset{p 14}{}}{R 3 [A] = R 5 [A]} ⋀ \underset{\underset{p 15}{}}{R 2 [A] = R 5 [A]} ⋀ \underset{\underset{p 16}{}}{R 2 [A] = cA} ⋀ \underset{\underset{p 17}{}}{R 2 [A] = R 4 [A]} ⋀ \underset{\underset{p 18}{}}{R 1 [A] = R 2 [A]} ⋀ \underset{\underset{p 19}{}}{R 3 [A] = cA} ⋀ \underset{\underset{p 20}{}}{R 2 [A] = R 3 [A]} ⋀ \underset{\underset{p 21}{}}{R 3 [A] = R 4 [A])}$
Based on the above query Q, cardinality estimator 172 generates one constant equivalence class to the predicate p′, where:
p′=((̂_i,jε{1,4,5}(Ri[A,B]=Rj[A,B]))̂(̂_iε{1,4,5}(Ri[A]=cÂRi[B]=cB)))
and the constant equivalence class cε(p′) is:
cε(p′)={R ₁ [A,B],R ₄ [A,B],R ₅ [A,B],(cA,cB)}
Cardinality estimator 172 then represents the constant equivalence class cε(p′) as graph G1=(V₁, E₁) where:


V₁= {R₁[A,B], R₄[A,B], R₅[A,B], (cA; cB)}
and
E₁= {
(R₁[A,B], R₄[A,B], (p9;p10)), (R₁[A,B], R₅[A,B], (p3; p4)),
(R₁[A,B], (cA, cB), (p7; p8)),
(R₄[A,B], R₅[A,B], (p11; p12)), (R₄[A,B], (cA, cB), (p5; p6)),
(R₅[A,B], (cA, cB), (p1; p2))
}

Graph G1(V₁, E₁), including the vertices V₁and edges E₁described above is illustrated in diagram 300A in FIG. 3A. Graph G1 is a graph showing a constant equivalence class for the predicate p′. Additionally, FIG. 3A also includes a listing of predicates p1 to p12 that comprise predicate p′ that defines the edges in graph G1.
In an embodiment, cardinality estimator 172 also generates a second equivalence class that corresponds to a predicate p″, where:
p″=((̂_{i,jε{1,2,3,4,5}}(Ri[A]=Rj[A]))̂(̂_{iε{1,2,3,4,5}}(Ri[A]=cA)
and where the constant equivalence class cε(p″) is:
cε(p″)={R ₁ [A],R ₂ [A],R ₃ [A],R ₄ [A],R ₅ [A],(cA)}
Cardinality estimator 172 then represents the constant equivalence class cε(p″) as graph G2=(V₂, E₂) where:


V₂= {R₁[A], R₂[A], R₃[A], R₄[A], R₅[A], (cA)}
and
E2 = {
(R₁[A,B], (cA,(R₁[A,B], (cA,(R₁[A], R₂[A],(p18)), (R₁[A], R₃[A],
(p13)), (R₁[A] ,R₄[A], (p9)); (R₁[A],
(R₁[A,B], (cA,(R₁[A,B], (cA,R₅[A], (p3), (R₁[A], (cA), (p7)),
(R₂[A], R₃[A], (p20)), (R₂[A], R₄[A], (p17)), (R₂[A], R₅[A], (p15)),
(R₂[A], (cA), (p16)),
(R₃[A], R₄[A], (p21)), (R₃[A], R₅[A], (p14)), (R₃[A], (cA), (p19)),
(R₄[A], R₅[A], (p11)), (R₄[A], (cA), (p5)),
(R₅[A], (cA); (p1))
}

Graph G2(V₂, E₂), including the vertices V₂and edges E₂described above is also illustrated in FIG. 3A. Graph G2 is a diagram of a constant equivalence class for the predicate p″. Additionally, FIG. 3A also includes a listing of predicates p1 to p21 that comprise predicate p″ and defines edges in graph G2.
Once, cardinality estimator 172 generates graphs for equivalence classes, such as example graphs G1 and G2 for example query Q, cardinality estimator 172 determines the spanning trees in the graphs. From the spanning trees, cardinality estimator 172 determines the minimum spanning tree and calculates the cardinality estimate from the minimum spanning tree as discussed below.
As shown in FIG. 3A, there may exist a predicate pi which annotates more than one edge in equivalence graphs corresponding to a query Q. For example, the predicate p5 annotates the edge (R₄[A, B], c(A, cB), (p5, p6)) in graph G1 and the edge (R₄[A], c(A), (p5)) in graph G2. When cardinality estimator 172 determines a cardinality estimate, cardinality estimator 172 generates a cardinality estimate based on a subset S of the join predicates representing some relationships of the relations {R₁, . . . R_n} that forms spanning trees. In an embodiment, cardinality estimator 172 excludes redundant (or repeating) predicates from the spanning tree.
For example, let a spanning tree T(G) be a tree in the fully connected, undirected graph G, that includes all vertices of graph G. In this case, a graph G having n vertices has n^(n-2) such spanning trees T(G). FIG. 3B is a diagram 300B of the example spanning tress of graphs G1 and G2, according to an embodiment. The dashed lines between the nodes in graphs G1 and G2 indicate the edges that are included in the spanning trees for graphs G1 and G2. The subset of predicates that are included in the spanning tree for graphs G1 and G2 are p5, p6, p7, p8, p11, p12, p14 and p20, as shown in bold in FIG. 3B.
To determine a spanning tree from a join equivalence graphs, such as G1 and G2, cardinality estimator 172 sets T(G(ε(p))) as a spanning tree of G(ε(p). The predicates in the spanning tree T(G(ε(p))) can be defined as a set of predicates annotating the edges in the spanning tree T(G(ε(p))). For example, predicates can be defined as:
Preds(T(G(ε(p))){p _i|(v ₁ ,v ₂,(p ₁ , . . . ,p _n)) an edge in T(G(ε(p)))}
In an embodiment, cardinality estimator 172 applies the following theorem to calculate cardinality estimation for query Q. If T(G(ε(p))) is a spanning tree of G(ε(p)), then the conjunct generated by the spanning tree infers the original predicate p, such as:
(̂_{cεPreds(T(G(ε(p))))} c)
p
Also, any predicate qε{p,|v₁, v₂, (p₁, . . . , p_n) an edge in G(ε(p))} is inferred by the conjunct generated by the spanning tree:
(̂_{cεPreds(T(G(ε(p))))} c)
q
Based on the theorem above, cardinality estimator 172 determines that a query Q, such as:
Q=σ _s(R ₁
. . .
R _n)
where a predicate s has e equivalent classes {ε(s₁), . . . , ε(s_e)} is equivalent to a query Q′ for which the predicate s was replaced with the predicates of a spanning trees induced by {T(G(ε(s₁))), . . . , T(Gε(s_e)))}.
Applying the theorem above, let {T(G(ε(s₁))), . . . , T(Gε(s_e)))} be spanning trees of a forest for graphs {G(ε(s₁))), . . . , Gε(s_e))}. In an embodiment, predicates of the forest for the graphs of join equivalence classes are predicates that annotate the spanning trees, with duplicates removed, such as:
Preds({T(G(ε(s ₁))), . . . ,T(G(ε(s _e)))})=∪_{iε{1, . . . e}} ^d(Preds(T(G(ε(s _i)))))
where cardinality estimator 172 uses operation ∪^dto remove duplicate predicates.
In an embodiment, cardinality estimator 172 rewrites query Q using the predicates in the forest of join equivalence classes Preds({T(G(ε(s₁))), . . . , T(Gε(s_e)))}), such as:
$Q = σ_{s} (R_{1} \dots R_{n}} = ? ((R_{1} \dots R_{n}) ? indicates text missing or illegible when filed$
In an embodiment, based on the theorem above, cardinality estimator 172 determines a cardinality estimate for query Q₀where:
Q _o=σ_x(R ₁
. . .
R _n)
by first rewriting the predicate x such that:
$Q_{0} = σ_{x^{'}} (\underset{\underset{Q}{}}{(σ_{s} (R_{1} \dots R_{n})}$
where cardinality estimator 172 can split predicate s into e join equivalence classes.
Cardinality estimator 172 then determines the cardinality of query Q₀. To determine cardinality of query Q₀, cardinality estimator 172 first determines the selectivity estimate of query Q using the spanning trees for the join predicate s referred to as selectivity(s). Cardinality estimator 172 then uses selectivity(s) to selectivity(x′) and the cardinalities of the relations R_ito compute card (Q₀), as illustrated below:
card(Q ₀)=f(selectivity(s),selectivity(x′),cardinality(R ₁), . . . ,cardinality(R _n))
In an embodiment, selectivity(s)=STSelectivity(Q) and can be computed using an algorithm in FIG. 8, according to an embodiment.
When cardinality estimator 172 applies the above algorithm to graphs G1 and G2 shown in FIGS. 3A and 3B, cardinality estimator 172 generates cardinality estimate 204 for query Q associated with graphs G1 and G2 as:
Cardinality Estimate=sel(p5̂p6)×sel(p7̂p8)×sel(p11̂p12)×sel(p20)×sel(p14)
FIG. 4 is a flowchart of a method 400 of a cardinality estimator generating a cardinality estimate for a query Q, according to an embodiment. Method 400 can be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions run on a processing device), or a combination thereof. In one implementation, the method 400 is performed by cardinality estimator 172.
At operation 402, the cardinality estimator receives a query Q. For example, cardinality estimator 172 receives query Q, where query Q=σ_s(R₁
. . .
R_n) and the predicate s can be split into e equivalent classes.
At operation 404, the cardinality estimator determines the minimum set of equivalence classes. For example, cardinality estimator 172 determines e equivalence classes {ε(s₁), . . . , ε(s_e)}. As discussed above, equivalence classes are determined based on sets of common attributes that are included in tables joined in query Q.
At operation 406, the cardinality estimator generates join equivalence graphs based on the minimum set of equivalence classes. For example, cardinality estimator 172 generates a forest of join equivalence graphs, each graph corresponding to a join equivalence class ε(s_i), where i=1 to e.
At operation 408, the cardinality estimator determines the minimum spanning tress for cardinality estimation. For example, in the join equivalence graphs, the edges represent predicate attributes, where each edge has a weight computed by DBMS 140. In an embodiment, the weight for an edge representing a join predicate between two tables is a property vector of the edge, including, for example, the confidence level of the selectivity estimation for an edge; the quality of the selectivity estimation expressed as the properties of the join predicates. Such properties may include a type of relationship between the two tables. Example properties include, if the join predicate is of the form “primary key primary key”, “primary key=foreign key”, “foreign key=foreign key”, “unique constraint attributes=attributes”, or “index attributes attributes”. When comparing the weights of two edges (during minimum spanning trees building) a function which compares the two property vectors of the edges can be used, according to an embodiment.
In an embodiment, cardinality estimator 172 determines the minimum spanning trees as the trees that include all vertices in the join equivalence graphs, such that the nodes of the graphs are connected using the edges associated with the lowest weights. In an embodiment, cardinality estimator 172 defines the spanning trees as {T(G(ε(s₁))), . . . , T(Gε(s_e)))}.
At operation 410, the cardinality estimator uses the predicate associated with the spanning trees to determine the cardinality estimate for query Q. For example, cardinality estimator 172 determines the cardinality estimate for query Q based on the predicates associated with edges of the minimum spanning trees determined in operation 408 and multiplied by the selectivity of these predicate, such as:
selectivity(s)=Π_{eεEdges({T(G(ε(s} ₁ _{))), . . . ,T(G(ε(s} _e _)))})(selectivity(e))
Once cardinality estimator 172 determines a cardinality estimate 204 for query Q, query optimizer 170 uses cardinality estimate 204 to determine a query plan from query Q.
In an embodiment, cardinality estimator 172 also determines a cardinality estimate for a sub-expression of query Q, such as sub-expression Q′. FIG. 5 is a flowchart of a method 500 of a cardinality estimator generating a cardinality estimate for a sub-section Q′ of query Q, according to an embodiment. Method 500 can be performed by processing logic that can comprise hardware (e.g., circuitry, dedicated logic, programmable logic, microcode, etc.), software (e.g., instructions run on a processing device), or a combination thereof. In one implementation, the method 500 is performed by cardinality estimator 172.
At operation 502, the cardinality estimator receives a query Q. For example, cardinality estimator 172 receives query Q, where query Q=σ_s(R₁
. . .
R_n) and the predicate s can be split into e equivalent classes.
At operation 504, the cardinality estimator receives a subset of tables. For example, cardinality estimator 172 receives a subset of tables that query Q manipulates, such as {Ri₁, . . . , Ri_t}⊂{Ri, . . . , Rn}.
At operation 506, the cardinality estimator determines the equivalence classes.
For example, cardinality estimator 172 determines e equivalence classes {ε(s₁), ε(s_e)}. As discussed above, equivalence classes are determined based on sets of common attributes that are included in tables joined in query Q.
At operation 508, the cardinality estimator generates join equivalence graphs. For example, cardinality estimator 172 generates a forest of join equivalence graph for each join equivalence class ε(s_i), where i=1 to e.
At operation 510, the cardinality estimator determines the sub-graphs from the join equivalence graphs that include the subset of tables. For example, for each graph G(ε(s_i)), cardinality estimator 172 determines the vertex induced sub-graph G′(ε(s_i)), where the vertex induced sub-graph G′(ε(s_i)) includes only vertices {Ri₁, . . . , Ri_t}. In an embodiment, cardinality estimator 172 represents the join equivalence sub-graphs as {G′(ε(s₁)), . . . , G′ε(s_e))}.
At operation 512, the cardinality estimator determines the minimum spanning tress for cardinality estimation. For example, in the join equivalence sub-graphs {G′(ε(s₁)), . . . , G′ε(s_e))}, the edges represent predicate attributes, where each predicate attribute has a weight specified by DBMS 140 as described above. In an embodiment, cardinality estimator 172 determines the minimum spanning trees as the trees that include all vertices in the join equivalence sub-graphs G′(ε(s_i)), such that the nodes of the graphs are connected using the edges associated with the lowest weights. In an embodiment, cardinality estimator 172 defines the spanning trees as {T(G(ε(s₁))), . . . , T(Gε(s_e)))}.
At operation 514, the cardinality estimator uses the predicate associated with the spanning trees to determine the cardinality estimate for sub-query Q′. For example, cardinality estimator 172 determines the selectivity estimation for sub-query Q′ based on the edges associated with the best spanning trees determined in operation 512 and multiplied by the selectivity of the predicate, such as:
selectivity(s′)=Π_{eεEdges({T(G′(ε(s} ₁ _{))), . . . ,T(G′(ε(s} _e _)))})(selectivity(e))
FIG. 6 is a diagram of an algorithm 600 for computing the cardinality of a query, according to an embodiment. Algorithm 600 may be implemented by cardinality estimator 172 to generate a cardinality estimate 204. Once cardinality estimator 172 receives query Q_o=σ_x(R₁
. . .
R_n), cardinality estimator 172 uses algorithm 600 to rewrite the predicate x to infer new predicates that complete join equivalence classes, such that Q_o=σ_x′(σ_s(R₁
. . .
R_n)), where Q=σ_s(R₁
. . .
R_n), and predicate s of query Q is split into e join equivalence classes. Algorithm 600 then uses algorithms 700-1000 discussed in FIGS. 7-10 to generate cardinality estimate 204 for query Q. Selectivity estimation for Q is computed by algorithm 800 (STSelectivity(Q) call). Algorithm 600 uses this new selectivity estimation and other estimates to compute the final cardinality estimation for the whole query Q₀(at line 3). The cardinality estimate is card(Q_o) is computed as:
card(Q _o)=f(selectivity(s),selectivity(x′),cardinality(R1), . . . ,cardinality(Rn)).
FIG. 7 is diagram of an algorithm 700 for determining join equivalence classes for a query, according to an embodiment. as required by cardinality estimator 172 during operations 404 and 506
As discussed above, cardinality estimator 172 determines join equivalence classes for a predicate. The input to algorithm 700 is a query Q, such as:
Q=σ _s(R ₁
. . .
R _n)
which can be decomposed into one or more equivalence classes. In an embodiment, the output of algorithm 700 is a minimum set of equivalence classes, such as such as {ε(s₁), . . . , ε(s_e)}. The details of algorithm 700 are included in FIG. 7.
FIG. 8 is a diagram of an algorithm 800 for computing a selectivity estimate for using spanning trees for a query used by cardinality estimator 172 during operation 204, according to an embodiment. The input to algorithm 800 is a query Q, such as:
Q=σ _s(R ₁
. . .
R _n)
The output of algorithm 800 is selectivity of a predicate s. In an embodiment, algorithm 800 uses algorithm 700 to generate a minimum set of the equivalence classes, such as set {ε(s₁), . . . , ε(s_e)}, at step 1. From the minimum set of the equivalence classes, cardinality estimator 172 generates graphs {G(ε(s₁))), . . . , Gε(s_e))}, one graph for each equivalence class, at step 2. Cardinality estimator 172 then uses algorithm 1000 to generate minimum spanning trees {T(G(ε(s₁))), . . . , T(Gε(s_e)))} from the graphs {G(ε(s₁))), G(ε(s_e))}, at step 3. At step 4, cardinality estimator uses the minimum spanning trees {T(G(ε(s₁))), . . . , T(Gε(s_e)))} to determine selectivity for predicate s.
FIG. 9 is a diagram of an algorithm 900 for computing the selectivity estimate for using spanning trees for a sub-query, according to an embodiment. The first input to algorithm 900 is a query Q, such as:
Q=σ _s(R ₁
. . .
R _n)
The second input to algorithm 900 is a subset of tables of tables in a query Q, such as:
{R _i1 , . . . ,R _it }⊂{R ₁ , . . . ,R _n}.
The output of algorithm 900 is an estimated selectivity of a sub-predicate s where s′ includes predicates on the subset {R_i1, . . . R_it}. In an embodiment, algorithm 900 uses algorithm 700 to generate a minimum set of the equivalence classes, such as set {ε(s₁), . . . , ε(s_e)}, at step 1. From the minimum set of the equivalence classes, cardinality estimator 172 generates graphs {G(ε(s₁))), . . . , Gε(s_e))}, one graph for each equivalence class, at step 2. Cardinality estimator 172 then computes a vertex induced sub-graph G′(ε(s_i)) for vertices of a subset of tables {R_i1, . . . . R_it}, at step 3. At step 4, cardinality estimator 172 determines, using the algorithm 1000, the minimum spanning trees {T(G′(ε(s₁))), . . . , T(G′(ε(s_e)))} from the new forest of sub-graph {G′(ε(s₁)), . . . , G′ε(s_e))}. At step 5, cardinality estimator 172 uses the minimum spanning trees {T(G′(ε(s₁))), . . . , T(G′(ε(s_e)))} to determine selectivity for predicate s′ for a sub-predicate s′, such as:
selectivity(s′)=Π_{eεEdges({T(G′(ε(s} ₁ _{))), . . . ,T(G′(ε(s} _e _)))})(selectivity(e))
FIG. 10 is a diagram of an algorithm 1000 for computing the minimum spanning trees, as required by cardinality estimator 172 during operations 408 and 512, for a graph forest of join equivalence classes, according to an embodiment. As discussed above, the edges in the a graph, such as graph {G(ε(s₁))), . . . , G(ε(s_e))}, have different weights. Cardinality estimator 172 may assign the weights to the edges based on a pre-configured criteria in DBMS 140. In an embodiment, cardinality estimator 172 may evaluate the weights to the edges based on a betterQuality(e_i, e_j) function which compares the two edges e_i, e_j, and determine the quality of the edge for inclusion into a minimum spanning tree. The betterQuality(e_i, e_j) function is included as part of algorithm 1000. Based on the quality of edges as determined by the weights, cardinality estimator 172 generates the minimum spanning trees from the forest of graphs {G(ε(s₁))), . . . , G(ε(s_e))}.
In an embodiment, the input to algorithm 1000 is the forest of graphs generated by the minimum set of join equivalence classes for query Q, such as, minε(Q)={G(ε(s₁)), . . . , G(ε(s_e)}. The output of algorithm 1000 is a set of best spanning trees {T(G(ε(s₁))), . . . , T(G(ε(s_e)))}.
In an embodiment, cardinality estimator 172 identifies the edges in the forest of graphs {G(ε(s₁))), . . . , G(ε(s_e))} in a set E, where E may be defines as:
E=∪ _{iε{1.ldots,e}}Edges(G(ε(s _i)))
Cardinality estimator 172 then uses algorithm 1000 to traverse though the edges using better Quality(e_i, e_j) function, and compare the edges in set E. When cardinality estimator 172 identifies an edge using better Quality(e_i, e_j) function, such as the edge having a lowest weight, algorithm 1000 adds the edge to a set of edges that together form the minimum spanning trees. In an embodiment, algorithm 1000 includes an add(d) function, where d is the edge identified using the betterQuality(e_i, e_j) function that cardinality estimator 172 attempts to add to the minimum spanning trees. The add(d) function is discussed in detail in FIG. 10.
Various embodiments can be implemented, for example, using one or more well-known computer systems, such as computer system 1100 shown in FIG. 11. Computer system 1100 can be any well-known computer capable of performing the functions described herein, such as computers available from International Business Machines, Apple, Sun, HP, Dell, Sony, Toshiba, etc.
Computer system 1100 includes one or more processors (also called central processing units, or (CPUs), such as a processor 1104. Processor 1104 is connected to a communication infrastructure or bus 1106.
One or more processors 1104 may each be a graphics processing unit (GPU). In an embodiment, a GPU is a processor that is a specialized electronic circuit designed to rapidly process mathematically intensive applications on electronic devices. The GPU may have a highly parallel structure that is efficient for parallel processing of large blocks of data, such as mathematically intensive data common to computer graphics applications, images and videos.
Computer system 1100 also includes user input/output device(s) 1103, such as monitors, keyboards, pointing devices, etc., which communicate with communication infrastructure 1106 through user input/output interface(s) 1102.
Computer system 1100 also includes a main or primary memory 1108, such as random access memory (RAM). Main memory 1308 may include one or more levels of cache. Main memory 1108 has stored therein control logic (i.e., computer software) and/or data.
Computer system 1100 may also include one or more secondary storage devices or memory 1110. Secondary memory 1110 may include, for example, a hard disk drive 1112 and/or a removable storage device or drive 1114. Removable storage drive 1114 may be a floppy disk drive, a magnetic tape drive, a compact disk drive, an optical storage device, tape backup device, and/or any other storage device/drive.
Removable storage drive 1114 may interact with a removable storage unit 1118. Removable storage unit 1118 includes a computer usable or readable storage device having stored thereon computer software (control logic) and/or data. Removable storage unit 1118 may be a floppy disk, magnetic tape, compact disk, DVD, optical storage disk, and/any other computer data storage device. Removable storage drive 1114 reads from and/or writes to removable storage unit 1118 in a well-known manner.
According to an exemplary embodiment, secondary memory 1110 may include other means, instrumentalities or other approaches for allowing computer programs and/or other instructions and/or data to be accessed by computer system 1100. Such means, instrumentalities or other approaches may include, for example, a removable storage unit 1122 and an interface 1120. Examples of the removable storage unit 1122 and the interface 1120 may include a program cartridge and cartridge interface (such as that found in video game devices), a removable memory chip (such as an EPROM or PROM) and associated socket, a memory stick and USB port, a memory card and associated memory card slot, and/or any other removable storage unit and associated interface.
Computer system 1100 may farther include a communication or network interface 1124. Communication interface 1124 enables computer system 1100 to communicate and interact with any combination of remote devices, remote networks, remote entities, etc. (individually and collectively referenced by reference number 1128). For example, communication interface 1124 may allow computer system 1100 to communicate with remote devices 1128 over communications path 1126, which may be wired and/or wireless, and which may include any combination of LANs, WANs, the Internet, etc. Control logic and/or data may be transmitted to and from computer system 1100 via communication path 1126.
In an embodiment, a tangible apparatus or article of manufacture comprising a tangible computer useable or readable medium having control logic (software) stored thereon is also referred to herein as a computer program product or program storage device. This includes, but is not limited to, computer system 1100, main memory 1108, secondary memory 1110, and removable storage units 1118 and 1122, as well as tangible articles of manufacture embodying any combination of the foregoing. Such control logic, when executed by one or more data processing devices (such as computer system 1100), causes such data processing devices to operate as described herein.
Based on the teachings contained in this disclosure, it will be apparent to persons skilled in the relevant art(s) how to make and use the embodiments using data processing devices, computer systems and/or computer architectures other than that shown in FIG. 11. In particular, embodiments may operate with software, hardware, and/or operating system implementations other than those described herein.
It is to be appreciated that the Detailed Description section, and not the Summary and Abstract sections (if any), is intended to be used to interpret the claims. The Summary and Abstract sections (if any) may set forth one or more but not all exemplary embodiments as contemplated by the inventor(s), and thus, are not intended to limit the embodiments or the appended claims in any way.
While the embodiments has been described herein with reference to exemplary embodiments for exemplary fields and applications, it should be understood that the embodiments are not limited thereto. Other embodiments and modifications thereto are possible, and are within the scope and spirit of the embodiments. For example, and without limiting the generality of this paragraph, embodiments are not limited to the software, hardware, firmware, and/or entities illustrated in the figures and/or described herein. Further, embodiments (whether or not explicitly described herein) have significant utility to fields and applications beyond the examples described herein.
Embodiments have been described herein with the aid of functional building blocks illustrating the implementation of specified functions and relationships thereof. The boundaries of these functional building blocks have been arbitrarily defined herein for the convenience of the description. Alternate boundaries can be defined as long as the specified functions and relationships (or equivalents thereof) are appropriately performed. Also, alternative embodiments may perform functional blocks, steps, operations, methods, etc. using orderings different than those described herein.
References herein to “one embodiment,” “an embodiment,” “an example embodiment,” or similar phrases, indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it would be within the knowledge of persons skilled in the relevant art(s) to incorporate such feature, structure, or characteristic into other embodiments whether or not explicitly mentioned or described herein.
The breadth and scope of the embodiments should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.

Claims

What is claimed is:

1. A computer-implemented method for generating a cardinality estimate, comprising:

identifying a predicate in a query, wherein the predicate is split into a plurality of equivalence classes;

generating a plurality of equivalence graphs from the plurality of equivalence classes;

identifying spanning trees from the plurality of equivalence graphs; and

generating a cardinality estimate based on the spanning trees.

2. The computer-implemented method of claim 1, wherein the query manipulates data in a plurality of tables, wherein a table includes a plurality of attributes.

3. The computer-implemented method of claim 1, wherein an equivalence class in the plurality of the equivalence classes shares a set of attributes common to the plurality of tables.

4. The computer-implemented method of claim 1, wherein an equivalence class in the plurality of the equivalence classes comprises a constant vector.

5. The computer-implemented method of claim 1, wherein generating an equivalence graph in the plurality of equivalence graphs, further comprises:

generating a first node and a second node, wherein the first node corresponds to a first table and a set of attributes and the second node corresponds to a second table and a set of attributes, wherein the first table, the second table and the attributes are included in an equivalence class from the plurality of the equivalence classes;

generating an edge between the first node and the second node; and

annotating the edge with a second predicate referencing the attributes between the first node and the second node, wherein the second predicate is a component of the query predicate.

6. The computer-implemented method of claim 5, wherein generating the equivalence graph further comprises:

generating a third node including a constant vector;

generating a second edge between a first node and a third node; and

annotating the second edge with a third predicate referencing the attributes between the second table and the constant vector, wherein the third predicate is a component of the query predicate.

7. The computer-implemented method of claim 1, wherein generating the cardinality estimate from the spanning trees, further comprises:

identifying a set of predicates in the spanning trees; and

multiplying for each predicate in the set of predicates by a selectivity associated with each edge corresponding to the predicate.

8. A system for generating a cardinality estimate, comprising:

a memory; and

a processor coupled to the memory and configured to:

identify a predicate in a query, wherein the predicate is split into a plurality of equivalence classes;

generate a plurality of equivalence graphs from the plurality of equivalence classes;

identify spanning trees from the plurality of equivalence graphs; and

generate a cardinality estimate based on the spanning trees.

9. The system of claim 8, wherein the query manipulates data in a plurality of tables, wherein a table includes a plurality of attributes.

10. The system of claim 8, wherein an equivalence class in the plurality of equivalence classes shares a set of attributes common to the plurality of tables.

11. The system of claim 8, wherein an equivalence class in the plurality of equivalence classes comprises a constant vector.

12. The system of claim 8, wherein to generate an equivalence graph in the plurality of the equivalence graphs, the processor is further configured to:

generate a first node and a second node, wherein the first node corresponds to a first table and a set of attributes and the second node corresponds to a second table and a set of attributes, wherein the first table, the second table and the attributes are included in an equivalence class in the plurality of equivalence classes;

generate an edge between the first node and the second node; and

annotate the edge with a second predicate referencing the attribute between the first node and the second node, wherein the second predicate is a component of the query predicate.

13. The system of claim 12, to generate the equivalence graph, the processor is further configured to:

generate a third node including a constant vector;

generate a second edge between a first node and a third node; and

annotate the second edge with a third predicate referencing the attributes between the second table and the constant vector, wherein the third predicate is a component of the query predicate.

14. The system of claim 8, wherein to generate the cardinality estimator from the spanning trees, the processor is further configured to:

identify a set of predicates in the spanning trees; and

multiply each predicate in the set of predicates by a selectivity associated with each edge corresponding to the predicate.

15. A tangible computer-readable device having instructions stored thereon that, when executed by at least one computing device, causes the at least one computing device to perform operations that generate a cardinality estimate, the operations comprising:

identifying spanning trees from the plurality of equivalence graphs; and

generating a cardinality estimate based on the spanning trees.

16. The tangible computer-readable device of claim 15, wherein the query manipulates data in a plurality of tables, wherein a table includes a plurality of attributes.

17. The tangible computer-readable device of claim 15, wherein an equivalence class in the plurality of equivalence classes shares a set of attributes common to the plurality of tables.

18. The tangible computer-readable device of claim 15, wherein an equivalence class in the plurality of equivalence classes comprises a constant vector.

19. The tangible computer-readable device of claim 15, wherein generating an equivalence graph in the plurality of equivalence graphs, further comprises operations comprising:

generating an edge between the first node and the second node; and

20. The tangible computer-readable device of claim 15, wherein generating the cardinality estimate from the sparring trees, further comprises operations, comprising:

identifying a set of predicates in the spanning trees; and