DETAILED ACTION
This Office action is in response to Applicant’s reply filed 11/12/2025.
Claims 1-20 are pending.
Claims 1, 5-6, 16; 17; and 19 are amended, of which claims 1, 17, and 19 are independent.
Claims 1-20 are rejected.
Notice of AIA Status
The present application, filed on or after March 16, 2013, is being examined under the first inventor to file provisions of the AIA .
Information Disclosure Statement
The information disclosure statement(s) (IDS) submitted on 11/12/2025 and 12/19/2025 were filed prior to this Office action. The submission is in compliance with the provisions of 37 CFR 1.97. Accordingly, the information disclosure statement(s) is/are being considered by the examiner.
Statutory Review under 35 USC § 101
Claims 1-16 are directed towards a method and have been reviewed.
Claims 1-16 appear to remain not directed to patent-eligible subject matter as they comprise an abstract idea without significantly more.
Claims 17-18 are directed toward a system and have been reviewed.
Claims 17-18 initially appear to remain non-statutory as the system does not expressly contain hardware. Claim 17 recites “one or more computers” and “a computer-readable medium.”
Regarding “one or more computers,” the instant specification FIG. 1, ¶ 0030-0031 is most relevant, describing “computer” as being “intended to encompass any suitable processing device. The database execution engine 108 and the client devices 102 may each be any computer or processing device…”
¶ 0031 recites, “Interfaces 150 and 152 are used by the client device 102A and the database execution engine 108, respectively, for communicating with other systems in a distributed environment - including within the system 100 - connected to the network 110. Generally, the interfaces 150 and 152 each comprise logic encoded in software and/or hardware in a suitable combination and operable to communicate with the network 110.”
However, the more likely interpretation of these passages given the language “one or more computers” and the language of the specification (despite reciting “interfaces 150 and 152 each compris[ing] logic encoded in software and/or hardware in a suitable combination”) is that “one or more computers” do not expressly comprise hardware.
Regarding “a computer-readable medium,” ¶ 0033 is most relevant, reciting, “Regardless of the particular implementation, ‘software’ may include computer-readable instructions, firmware, wired and/or programmed hardware, or any combination thereof on a tangible medium (transitory or non-transitory, as appropriate) operable when executed to perform at least the processes and operations described herein.”
However, “computer-readable instructions … on a tangible medium” is not identical to a non-transitory interpretation of a “computer-readable medium.”
As a result, “computer-readable medium” is not being considered hardware at this time.
Claims 17-18 also perform the method of claims 1-2, which appear to remain not directed to patent-eligible subject matter as they comprise an abstract idea without significantly more.
Claims 19-20 are directed toward an article of manufacture and have been reviewed.
Claims 19-20 appear to remain non-statutory, as the article of manufacture can be interpreted to include non-statutory subject matter (i.e., transitory propagating signals).
Claim 19 does recite “a non-transitory storage medium”; however, claim 19 is drawn to a “computer program product encoded on a non-transitory storage medium” and can be interpreted as comprising the “computer program product” but not the “non-transitory storage medium.”
Claims 19-20 also perform the method of claims 1-2, which appear to remain not directed to patent-eligible subject matter as they comprise an abstract idea without significantly more.
Response to Arguments
35 U.S.C. 101
Applicant's arguments filed 11/12/2025 have been fully considered but they are not persuasive.
Regarding claim 1, Applicant argues that the Present Application is directed to the practical application of dynamically improving database system performance and does so through specific technical operations that require advanced computing methods to perform.
In response to Applicant’s arguments, the claims do not recite the purported dynamically improved database system performance, mentioning only language such as “receiving, at a database system, a query for a database table” and “executing the query, in the database system, according to [a] modified query plan.”
In order to realize the dynamically improved database system performance, adjustments to the claim language are recommended.
Applicant further argues that ¶ 0012 of the Present Application provides a technical solution for the technical problem, “thus saving significant computing resources as compared to a single approach or other approaches.”
In response to Applicant’s arguments, the claims do not recite the purported saving of significant computing resources; in order to realize the saving of significant computing resources, adjustments to the claim language are recommended.
Applicant further argues that ¶ 0028 of the Present Application provides further details regarding the claimed technical solution for the technical problem, as “some cases may see some performance degradation if predicate evaluation is performed using worst-case data. To avoid these degradation case while still achieving benefits of worst-case approaches…”
In response to Applicant’s arguments, the claims do not recite the purported avoidance of performance degradation. Relevant is dependent claim 6, referring to a previously-determined predicate evaluation order being based at least on estimated worst-case selectivities for predicates in the set of multiple predicates.
However, dependent claim 6 is currently not in condition to be considered patent-eligible subject matter. In order to realize the avoidance of performance degradation, adjustments to the claim language are recommended, such as adjustments to show the improvement to performance of the modified query plan in contrast to performance of the (identified) query plan and/or performance in the worst-case scenario of the estimated worst-case selectivities, in whatever embodiment is fully supported by the specification.
Applicant further submits that the claimed solution is a technical improvement that improves the database system itself, referring to ¶ 0020 and ¶ 0054 of the Present Application.
In response to Applicant’s arguments, the claims are currently structured in a manner where an abstract idea is being performed on a database system as opposed to a database system being improved by the elements of the claims.
The additional elements are not currently considered to be improving the functioning of a computer, as desired in the first listing of MPEP 2106.04(d), Section I, but more closely align with the second listing of MPEP 2106.04(d), “merely including instructions to implement an abstract idea on a computer, or merely using a computer as a tool to perform an abstract idea,” or “generally linking the use of a judicial exception to a particular technological environment or field of use.”
Ultimately, Applicant submits that the claims, when considered under the new Guidance and revised MPEP, recite eligible subject matter.
In response to Applicant’s arguments, the Examiner is currently not convinced that the claims are currently in condition to be considered patent-eligible subject matter.
35 U.S.C. 102/35 US.C. 103
Applicant’s arguments, see pp10-13, filed 11/12/2025, with respect to the rejection(s) of claim(s) 1, 17, and 19 under 35 U.S.C. 102 have been fully considered and are persuasive. Therefore, the rejection has been withdrawn. However, upon further consideration, a new ground(s) of rejection is made under 35 U.S.C. 103 as being unpatentable over Alpers in view of newly incorporated reference Faunce.
Claim Analysis - 35 USC § 101
Claims 1-16 remain rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 2A, Prong One
Claim 1 recites identifying a query plan, determining runtime estimated selectivities of predicates, and determining matching value counts of predicates, which is a mental process (including an observation, evaluation, judgment, opinion).
Determining selectivities of predicates is determining a percentage of table rows that match the predicate.
Determining matching value counts of predicates is determining how many distinct rows/entries fulfill the predicate condition such as “A=10” or “B<2.”
Step 2A, Prong Two
This judicial exception of identifying a query plan, determining runtime estimated selectivities of predicates, and determining matching value counts of predicates is not integrated into a practical application despite the generically recited computer elements shown below:
a database system
a database table
The generically recited computer elements amount to implementing the abstract idea on a computer, merely using a computer as a tool to perform an abstract idea, or generally linking the use of a judicial exception to a particular technological environment or field of use as seen below.
receiving, at a database system, a query … wherein the query includes a set of parameter values or a set of predicates;
These additional elements are mere data gathering which is considered to be insignificant extra solution activity (MPEP 2106.05(g)).
modifying the query plan with respect to at least one predicate based on at least one of the runtime estimated selectivities or the matching value counts, to generate a modified query plan;
These additional elements are mere generic transmission and presentation of collected and analyzed data which is considered to be insignificant extra solution activity (MPEP 2106.05(g)).
a query for a database table,
executing the query, in the database system, according to the modified query plan.
In Berkheimer v. HP, Inc., 881 F.3d 1360, 125 USPQ2d 1649 (Fed. Cir. 2018), the patentee claimed methods for parsing and evaluating data using a computer processing system.
Specifically, the claims also included parsing an item into a plurality of multi-part object structures wherein portions of the structures have searchable information tags associated therewith, then evaluating the object structures in accordance with object structures previously stored in an archive.
The Federal Circuit determined that these claims were directed to mental processes of parsing and comparing data, because the steps were recited at a high level of generality and merely used computers as a tool to perform the processes.
Similarly, as the claims of Berkheimer involve generating a query and executing a query, claim 1 uses a computer to generate its query.
As a result, this additional element merely uses a computer as a tool to perform an abstract idea (see MPEP 2160.05(a)(2)(III)(C)).
Step 2B
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception despite the additional elements shown below:
receiving, at a database system, a query for a database table, wherein the query includes a set of parameter values or a set of predicates;
executing the query, in the database system, according to the modified query plan.
This performs receiving or transmitting data over a network, which are well-understood, routine, conventional computer functions as recognized by the court decisions listed in MPEP § 2106.05(d), specifically MPEP § 2106.05(d)(II)(i).
modifying the query plan with respect to at least one predicate based on at least one of the runtime estimated selectivities or the matching value counts, to generate a modified query plan;
These additional elements are well-understood, routine, and conventional activities when they are claimed in a merely generic manner.
Claim 2 specifies the predicate evaluation strategy to be a data vector scan strategy; however, claim 2 does not add a meaningful limitation as these are merely nominal or token extra-solution components of the claim and serves only as an attempt to generally link the product of nature to a further particular technological environment (see MPEP 2106.05(h)).
Claim 3 specifies the predicate evaluation strategy to be an index lookup strategy; however, claim 3 does not add a meaningful limitation as these are merely nominal or token extra-solution components of the claim and serves only as an attempt to generally link the product of nature to a further particular technological environment (see MPEP 2106.05(h)).
Claim 4 specifies that the predicate evaluation order was previously determined; however, claim 8 does not add a meaningful limitation as these are merely nominal or token extra-solution components of the claim.
Claim 5 specifies the predicate evaluation strategy was previously determined, previously determined based at least on compile-time estimated selectivities; however, claim 5 does not add a meaningful limitation as these are merely nominal or token extra-solution components of the claim and serves only as an attempt to generally link the product of nature to a further particular technological environment (see MPEP 2106.05(h)).
Claim 6 specifies the predicate evaluation strategy was previously determined, previously determined based at least on worst-case selectivities; however, claim 6 does not add a meaningful limitation as these are merely nominal or token extra-solution components of the claim and serves only as an attempt to generally link the product of nature to a further particular technological environment (see MPEP 2106.05(h)).
Claim 7 specifies changing the predicate evaluation order based on at least one runtime estimated predicate selectivity being more than a first threshold; however, claim 7 does not add a meaningful limitation as these are merely nominal or token extra-solution components of the claim.
Claim 8 specifies changing the predicate evaluation strategy from an index lookup to a data vectors can strategy based on a matching value count being more than a second threshold; however, claim 8 does not add a meaningful limitation as these are merely nominal or token extra-solution components of the claim and serves only as an attempt to generally link the product of nature to a further particular technological environment (see MPEP 2106.05(h)).
Claims 9-11 specify changing the predicate evaluation strategy; however, claims 9-11 do not add a meaningful limitation as these are merely nominal or token extra-solution components of the claim and serves only as an attempt to generally link the product of nature to a further particular technological environment (see MPEP 2106.05(h)).
Claim 12 defines a runtime estimated selectivity of a first predicate; claim 12 does not add a meaningful limitation as these are merely nominal or token extra-solution components of the claim and serves only as an attempt to generally link the product of nature to a further particular technological environment (see MPEP 2106.05(h)).
Claim 13 recites determining a runtime estimated selectivity of a first predicate based on locating a first parameter value (in frequency statistic metadata for the database table), which is a mental process.
Claim 14 recites determining a runtime estimated selectivity of a first predicate (based on sampling a database table and determining how many sampled rows of the database table match the first predicate), which is a mental process.
Claim 15 recites determining that a column referenced in the first predicate stores unique values and determining a runtime estimated selectivity of the first predicate by dividing a value of one by a row count (of the database table), which is a mental process.
Claims 17-18 remain rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 2A, Prong One
Claim 17 recites identifying a query plan, determining runtime estimated selectivities of predicates, and determining matching value counts of predicates, which is a mental process (including an observation, evaluation, judgment, opinion).
Determining selectivities of predicates is determining a percentage of table rows that match the predicate.
Determining matching value counts of predicates is determining how many distinct rows/entries fulfill the predicate condition such as “A=10” or “B<2.”
Step 2A, Prong Two
This judicial exception of identifying a query plan, determining runtime estimated selectivities of predicates, and determining matching value counts of predicates is not integrated into a practical application despite the generically recited computer elements shown below:
a database system
a database table
The generically recited computer elements amount to implementing the abstract idea on a computer, merely using a computer as a tool to perform an abstract idea, or generally linking the use of a judicial exception to a particular technological environment or field of use as seen below.
one or more computers;
This additional element merely uses a computer as a tool to perform an abstract idea (see MPEP 2160.05(f)).
receiving, at a database system, a query … wherein the query includes a set of parameter values or a set of predicates;
These additional elements are mere data gathering which is considered to be insignificant extra solution activity (MPEP 2106.05(g)).
modifying the query plan with respect to at least one predicate based on at least one of the runtime estimated selectivities or the matching value counts, to generate a modified query plan;
These additional elements are mere generic transmission and presentation of collected and analyzed data which is considered to be insignificant extra solution activity (MPEP 2106.05(g)).
a query for a database table,
executing the query, in the database system, according to the modified query plan.
In Berkheimer v. HP, Inc., 881 F.3d 1360, 125 USPQ2d 1649 (Fed. Cir. 2018), the patentee claimed methods for parsing and evaluating data using a computer processing system.
Specifically, the claims also included parsing an item into a plurality of multi-part object structures wherein portions of the structures have searchable information tags associated therewith, then evaluating the object structures in accordance with object structures previously stored in an archive.
The Federal Circuit determined that these claims were directed to mental processes of parsing and comparing data, because the steps were recited at a high level of generality and merely used computers as a tool to perform the processes.
Similarly, as the claims of Berkheimer involve generating a query and executing a query, claim 1 uses a computer to generate its query.
As a result, this additional element merely uses a computer as a tool to perform an abstract idea (see MPEP 2160.05(a)(2)(III)(C)).
Step 2B
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception despite the additional elements shown below:
a computer-readable medium
These elements store and retrieve information in memory, which are well-understood, routine, conventional computer functions as recognized by the court decisions listed in MPEP § 2106.05(d).
receiving, at a database system, a query for a database table, wherein the query includes a set of parameter values or a set of predicates;
executing the query, in the database system, according to the modified query plan.
This performs receiving or transmitting data over a network, which are well-understood, routine, conventional computer functions as recognized by the court decisions listed in MPEP § 2106.05(d), specifically MPEP § 2106.05(d)(II)(i).
modifying the query plan with respect to at least one predicate based on at least one of the runtime estimated selectivities or the matching value counts, to generate a modified query plan;
These additional elements are well-understood, routine, and conventional activities when they are claimed in a merely generic manner.
Claim 18 specifies the predicate evaluation strategy to be a data vector scan strategy; however, claim 18 does not add a meaningful limitation as these are merely nominal or token extra-solution components of the claim and serves only as an attempt to generally link the product of nature to a further particular technological environment (see MPEP 2106.05(h)).
Claims 19-20 remain rejected under 35 U.S.C. 101 because the claimed invention is directed to an abstract idea without significantly more.
Step 2A, Prong One
Claim 19 recites identifying a query plan, determining runtime estimated selectivities of predicates, and determining matching value counts of predicates, which is a mental process (including an observation, evaluation, judgment, opinion).
Determining selectivities of predicates is determining a percentage of table rows that match the predicate.
Determining matching value counts of predicates is determining how many distinct rows/entries fulfill the predicate condition such as “A=10” or “B<2.”
Step 2A, Prong Two
This judicial exception of identifying a query plan, determining runtime estimated selectivities of predicates, and determining matching value counts of predicates is not integrated into a practical application despite the generically recited computer elements shown below:
a database system
a database table
The generically recited computer elements amount to implementing the abstract idea on a computer, merely using a computer as a tool to perform an abstract idea, or generally linking the use of a judicial exception to a particular technological environment or field of use as seen below.
one or more processors
This additional element merely uses a computer as a tool to perform an abstract idea (see MPEP 2160.05(f)).
receiving, at a database system, a query … wherein the query includes a set of parameter values or a set of predicates;
These additional elements are mere data gathering which is considered to be insignificant extra solution activity (MPEP 2106.05(g)).
modifying the query plan with respect to at least one predicate based on at least one of the runtime estimated selectivities or the matching value counts, to generate a modified query plan;
These additional elements are mere generic transmission and presentation of collected and analyzed data which is considered to be insignificant extra solution activity (MPEP 2106.05(g)).
a query for a database table,
executing the query, in the database system, according to the modified query plan.
In Berkheimer v. HP, Inc., 881 F.3d 1360, 125 USPQ2d 1649 (Fed. Cir. 2018), the patentee claimed methods for parsing and evaluating data using a computer processing system.
Specifically, the claims also included parsing an item into a plurality of multi-part object structures wherein portions of the structures have searchable information tags associated therewith, then evaluating the object structures in accordance with object structures previously stored in an archive.
The Federal Circuit determined that these claims were directed to mental processes of parsing and comparing data, because the steps were recited at a high level of generality and merely used computers as a tool to perform the processes.
Similarly, as the claims of Berkheimer involve generating a query and executing a query, claim 1 uses a computer to generate its query.
As a result, this additional element merely uses a computer as a tool to perform an abstract idea (see MPEP 2160.05(a)(2)(III)(C)).
Step 2B
The claim(s) does/do not include additional elements that are sufficient to amount to significantly more than the judicial exception despite the additional elements shown below:
A computer program product
These elements store and retrieve information in memory, which are well-understood, routine, conventional computer functions as recognized by the court decisions listed in MPEP § 2106.05(d).
receiving, at a database system, a query for a database table, wherein the query includes a set of parameter values or a set of predicates;
executing the query, in the database system, according to the modified query plan.
This performs receiving or transmitting data over a network, which are well-understood, routine, conventional computer functions as recognized by the court decisions listed in MPEP § 2106.05(d), specifically MPEP § 2106.05(d)(II)(i).
modifying the query plan with respect to at least one predicate based on at least one of the runtime estimated selectivities or the matching value counts, to generate a modified query plan;
These additional elements are well-understood, routine, and conventional activities when they are claimed in a merely generic manner.
Claim 20 specifies the predicate evaluation strategy to be a data vector scan strategy; however, claim 20 does not add a meaningful limitation as these are merely nominal or token extra-solution components of the claim and serves only as an attempt to generally link the product of nature to a further particular technological environment (see MPEP 2106.05(h)).
Claim Rejections - 35 USC § 103
The following is a quotation of 35 U.S.C. 103 which forms the basis for all obviousness rejections set forth in this Office action:
A patent for a claimed invention may not be obtained, notwithstanding that the claimed invention is not identically disclosed as set forth in section 102, if the differences between the claimed invention and the prior art are such that the claimed invention as a whole would have been obvious before the effective filing date of the claimed invention to a person having ordinary skill in the art to which the claimed invention pertains. Patentability shall not be negated by the manner in which the invention was made.
Claims 1, 3, 5-7, 12-15; 17; and 19 are rejected under 35 U.S.C. 103 as being unpatentable over Alpers et al., U.S. Patent Application Publication No. 2017/0249360 (hereinafter Alpers) in view of Zhang et al., U.S. Patent Application Publication No. 2009/0299989 (hereinafter Zhang).
Regarding claim 1, Alpers teaches:
A computer-implemented method comprising: receiving, at a database system, a query for a database table, wherein the query includes a set of parameter values for a set of … predicates; (Alpers FIG. 1, ¶ 0019: In diagram 100, a relational database management system (RDBMS) is provided with a structure query language (SQL) statement 110. The SQL statement 110 includes a predicate 112 (referred to as a join predicate) with a table join 114 and a column of one of the tables constrained to a variable 116)
identifying a query plan for the query that includes a predicate evaluation order for the set of … predicates and a predicate evaluation strategy for each predicate in the set of … predicates; (Alpers shows 'predicate evaluation order' in ¶ 0032-0033, see first ¶ 0032: the needed data for a query can be collected from a database by accessing it in different ways, through different data-structures, and in different orders; see then ¶ 0033: The access path selector 324 selects one of the query plans available to the query optimizer 312 given the estimate (which has estimated selectively of the join predicate). The access path or query plan as used herein represents an ordered set of steps used to access data in a SQL RDBMS (e.g., database repository 330 information); Alpers shows 'predicate evaluation strategy' through its access paths; see Alpers ¶ 0002: Two access paths available to a query optimizer that produces equivalent results include a table scan access path and an index access path; Alpers ¶ 0006: If the estimated quantity of records is greater than a previously determined threshold, the query optimizer optimizes the RDBMS query using a first access path. If the estimated quantity of records is not greater than a previously determined threshold, the query optimizer optimizes the RDBMS query using a second access path. The first access path and the second access path produce functionally equivalent results while having disparate computational speeds to produce the equivalent results; see also Alpers ¶ 0022-0023: the query optimizer executes (142) an access path for the SQL query 110, which is designed to handle a relatively large number of records (in the join predicate 120) [shows the claimed evaluation strategy involving predicates])
determining runtime estimated selectivities by determining a … runtime estimated selectivity for … the set of … predicates based on respective parameter values in the set of parameter values; (Alpers introduces estimated selectivities of predicates as claimed in FIG. 3, ¶ 0010: compute an estimate of records returned for a join predicate to estimate selectively (i.e., inverse of amount of record skew) during query optimization; Alpers ¶ 0032-0033: the query optimizer 312 estimates selectivity across a predicate to pick a better plan than possible if this estimate were not performed … The first time a join occurs on a particular column across two tables, a onetime small overhead estimate for optimization purposes can be performed. The skew estimator 322 performs this estimate, and saves results in the data store 318 for future use by the query optimizer 312. In one embodiment, as records within the respective database repository 330 change over time, skew can change and the estimate for a join predicate can be re-executed [shows being based on 'respective parameter values' as claimed])
determining matching value counts by determining a … matching value count for … the set of … predicates, wherein each matching value count indicates a count of distinct values that match a respective predicate; (Alpers FIG. 1, ¶ 0021-0023, see first ¶ 0021: Diagram 100 estimates the join predicate record return by conducting a query localized to T2 (or to one of the tables of the join predicate) ... A count query 132 is conducted local to table two (T2) where the T2.Col1 is set to the high skew value 127, and where any other local variables (T2.C3) are set to the proper values consistent with the SQL query 110; see also Alpers ¶ 0022: After the SQL count query 132 is executed to estimate the join predicate 120 record quantity, the estimated number of records can be compared against a predefined quantity (e.g., a threshold), as shown by decision block 140. As shown, the count results (from query 132) are compared against a threshold value of fifty)
modifying the query plan with respect to at least one predicate based on at least one of the runtime estimated selectivities or the matching value counts, to generate a modified query plan; and (Alpers FIG. 1, ¶ 0021-0023, see mostly ¶ 0022 showing the claimed 'matching value counts': the count results (from query 132) are compared against a threshold value of fifty. If the estimate is greater than the threshold, the query optimizer executes (142) an access path for the SQL query 110, which is designed to handle a relatively large number of records (in the join predicate 120) in an optimal manner ... If the count result does not exceed the threshold (in decision block 140), the query optimizer 120 can optimize the RDBMS query 110 using a different access path, as shown by block 144; see also Alpers FIG. 2, step 255, ¶ 0027: In step 240, if the quantity of records (estimated per step 235) [also shows 'matching value counts'] is greater than a previously determined threshold, the process can continue to step 245, where the query optimizer can optimize the query per a first access path [shows 'modifying' of a query plan] ... step 250 can execute where the query optimizer selects a second access path (optimized for a relatively low quantity of records resulting from the join predicate) [shows being 'with respect to at least one predicate']; see Alpers ¶ 0033 showing involvement of the claimed 'runtime estimated selectivities': The access path selector 324 selects one of the query plans available to the query optimizer 312 given the estimate (which has estimated selectively of the join predicate))
executing the query, in the database system, according to the modified query plan. (Alpers FIG. 2, step 255, ¶ 0027: In step 255, the RDBMS query can execute using the query optimizer determined access path (access path one or access path two depending on results from step 240 as shown); see Alpers ¶ 0006: a computer program product for skew-sensitive query optimization across join predicates in a relational database management system (RDMBS). In this aspect, a RDBMS query can be received at a query optimizer)
Alpers does not expressly disclose a set of multiple predicates.
Alpers further does not expressly disclose:
determining runtime estimated selectivities by determining a respective runtime estimated selectivity for each predicate in the set of multiple predicates based on respective parameter values in the set of parameter values;
determining matching value counts by determining a respective matching value count for each predicate in the set of multiple predicates,
However, Zhang addresses this by teaching the following.
Zhang teaches “a set of multiple predicates” and further teaches “wherein the query includes a set of parameter values for a set of multiple predicates.” (Zhang pp4-5, ¶ 0052-0054: a query optimizer calculates the selectivity of each of order key predicate separately and subsequently multiplies them together … In SQL Statement Example 1, there are two path identifier predicates (lines 4-5) and three order key predicates (lines 6-8))
Zhang further teaches:
determining runtime estimated selectivities by determining a respective runtime estimated selectivity for each predicate in the set of multiple predicates based on respective parameter values in the set of parameter values; (Zhang pp4-5, ¶ 0058-0061: In SQL Statement Example 1, the selectivity of the predicate at line 4 may be determined using Synopsis Example 1 … the selectivity of predicate P1.pathid=PATHTOID(`/A/B`) is 4/14 … Similarly, the selectivity of the predicate at line 5 (P2.pathid=PATHTOID(`/A/B/D`)) may be determined from Synopsis Example 1. The selectivity of this predicate is 2/14 because there are two (2) elements under the path/A/BID)
determining matching value counts by determining a respective matching value count for each predicate in the set of multiple predicates, (Zhang pp4-5, ¶ 0058-0061: From Synopsis Example 1, it is determined that the number of elements in XML Document Example 1 is 14 (e.g., "count" of element A+"descendants_cnt" of element A). Also from Synopsis Example 1, it is determined that the number of elements under the path/A/B is four (4) (e.g., "count" of element B) ... The selectivity of this predicate is 2/14 because there are two (2) elements under the path/A/BID)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the query plans of Alpers with the query planning of Zhang.
In addition, both of the references (Alpers and Zhang) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as query plan management and execution.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to optimize queries executed by a database system as seen in Zhang ¶ 0002.
Regarding claim 17, Alpers teaches:
A system comprising: one or more computers; and a computer-readable media coupled to the one or more computers having instructions stored thereon which, when executed by the one or more computers, cause the one or more computers to perform operations comprising: (Alpers ¶ 0016-0018: These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner; ¶ 0028: a network 302 communicatively links one or more computing devices 340)
receiving, at a database system, a query for a database table, wherein the query includes a set of parameter values for a set of … predicates; (Alpers FIG. 1, ¶ 0019: In diagram 100, a relational database management system (RDBMS) is provided with a structure query language (SQL) statement 110. The SQL statement 110 includes a predicate 112 (referred to as a join predicate) with a table join 114 and a column of one of the tables constrained to a variable 116)
identifying a query plan for the query that includes a predicate evaluation order for the set of … predicates and a predicate evaluation strategy for each predicate in the set of … predicates; (Alpers shows 'predicate evaluation order' in ¶ 0032-0033, see first ¶ 0032: the needed data for a query can be collected from a database by accessing it in different ways, through different data-structures, and in different orders; see then ¶ 0033: The access path selector 324 selects one of the query plans available to the query optimizer 312 given the estimate (which has estimated selectively of the join predicate). The access path or query plan as used herein represents an ordered set of steps used to access data in a SQL RDBMS (e.g., database repository 330 information); Alpers shows 'predicate evaluation strategy' through its access paths; see Alpers ¶ 0002: Two access paths available to a query optimizer that produces equivalent results include a table scan access path and an index access path; Alpers ¶ 0006: If the estimated quantity of records is greater than a previously determined threshold, the query optimizer optimizes the RDBMS query using a first access path. If the estimated quantity of records is not greater than a previously determined threshold, the query optimizer optimizes the RDBMS query using a second access path. The first access path and the second access path produce functionally equivalent results while having disparate computational speeds to produce the equivalent results; see also Alpers ¶ 0022-0023: the query optimizer executes (142) an access path for the SQL query 110, which is designed to handle a relatively large number of records (in the join predicate 120) [shows the claimed evaluation strategy involving predicates])
determining runtime estimated selectivities by determining a … runtime estimated selectivity for … the set of … predicates based on respective parameter values in the set of parameter values; (Alpers introduces estimated selectivities of predicates as claimed in FIG. 3, ¶ 0010: compute an estimate of records returned for a join predicate to estimate selectively (i.e., inverse of amount of record skew) during query optimization; Alpers ¶ 0032-0033: the query optimizer 312 estimates selectivity across a predicate to pick a better plan than possible if this estimate were not performed … The first time a join occurs on a particular column across two tables, a onetime small overhead estimate for optimization purposes can be performed. The skew estimator 322 performs this estimate, and saves results in the data store 318 for future use by the query optimizer 312. In one embodiment, as records within the respective database repository 330 change over time, skew can change and the estimate for a join predicate can be re-executed [shows being based on 'respective parameter values' as claimed])
determining matching value counts by determining a … matching value count for … the set of … predicates, wherein each matching value count indicates a count of distinct values that match a respective predicate; (Alpers FIG. 1, ¶ 0021-0023, see first ¶ 0021: Diagram 100 estimates the join predicate record return by conducting a query localized to T2 (or to one of the tables of the join predicate) ... A count query 132 is conducted local to table two (T2) where the T2.Col1 is set to the high skew value 127, and where any other local variables (T2.C3) are set to the proper values consistent with the SQL query 110; see also Alpers ¶ 0022: After the SQL count query 132 is executed to estimate the join predicate 120 record quantity, the estimated number of records can be compared against a predefined quantity (e.g., a threshold), as shown by decision block 140. As shown, the count results (from query 132) are compared against a threshold value of fifty)
modifying the query plan with respect to at least one predicate based on at least one of the runtime estimated selectivities or the matching value counts, to generate a modified query plan; and (Alpers FIG. 1, ¶ 0021-0023, see mostly ¶ 0022 showing the claimed 'matching value counts': the count results (from query 132) are compared against a threshold value of fifty. If the estimate is greater than the threshold, the query optimizer executes (142) an access path for the SQL query 110, which is designed to handle a relatively large number of records (in the join predicate 120) in an optimal manner ... If the count result does not exceed the threshold (in decision block 140), the query optimizer 120 can optimize the RDBMS query 110 using a different access path, as shown by block 144; see also Alpers FIG. 2, step 255, ¶ 0027: In step 240, if the quantity of records (estimated per step 235) [also shows 'matching value counts'] is greater than a previously determined threshold, the process can continue to step 245, where the query optimizer can optimize the query per a first access path [shows 'modifying' of a query plan] ... step 250 can execute where the query optimizer selects a second access path (optimized for a relatively low quantity of records resulting from the join predicate) [shows being 'with respect to at least one predicate']; see Alpers ¶ 0033 showing involvement of the claimed 'runtime estimated selectivities': The access path selector 324 selects one of the query plans available to the query optimizer 312 given the estimate (which has estimated selectively of the join predicate))
executing the query, in the database system, according to the modified query plan. (Alpers FIG. 2, step 255, ¶ 0027: In step 255, the RDBMS query can execute using the query optimizer determined access path (access path one or access path two depending on results from step 240 as shown); see Alpers ¶ 0006: a computer program product for skew-sensitive query optimization across join predicates in a relational database management system (RDMBS). In this aspect, a RDBMS query can be received at a query optimizer)
Alpers does not expressly disclose a set of multiple predicates.
Alpers further does not expressly disclose:
determining runtime estimated selectivities by determining a respective runtime estimated selectivity for each predicate in the set of multiple predicates based on respective parameter values in the set of parameter values;
determining matching value counts by determining a respective matching value count for each predicate in the set of multiple predicates,
However, Zhang addresses this by teaching the following.
Zhang teaches “a set of multiple predicates” and further teaches “wherein the query includes a set of parameter values for a set of multiple predicates.” (Zhang pp4-5, ¶ 0052-0054: a query optimizer calculates the selectivity of each of order key predicate separately and subsequently multiplies them together … In SQL Statement Example 1, there are two path identifier predicates (lines 4-5) and three order key predicates (lines 6-8))
Zhang further teaches:
determining runtime estimated selectivities by determining a respective runtime estimated selectivity for each predicate in the set of multiple predicates based on respective parameter values in the set of parameter values; (Zhang pp4-5, ¶ 0058-0061: In SQL Statement Example 1, the selectivity of the predicate at line 4 may be determined using Synopsis Example 1 … the selectivity of predicate P1.pathid=PATHTOID(`/A/B`) is 4/14 … Similarly, the selectivity of the predicate at line 5 (P2.pathid=PATHTOID(`/A/B/D`)) may be determined from Synopsis Example 1. The selectivity of this predicate is 2/14 because there are two (2) elements under the path/A/BID)
determining matching value counts by determining a respective matching value count for each predicate in the set of multiple predicates, (Zhang pp4-5, ¶ 0058-0061: From Synopsis Example 1, it is determined that the number of elements in XML Document Example 1 is 14 (e.g., "count" of element A+"descendants_cnt" of element A). Also from Synopsis Example 1, it is determined that the number of elements under the path/A/B is four (4) (e.g., "count" of element B) ... The selectivity of this predicate is 2/14 because there are two (2) elements under the path/A/BID)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the query plans of Alpers with the query planning of Zhang.
In addition, both of the references (Alpers and Zhang) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as query plan management and execution.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to optimize queries executed by a database system as seen in Zhang ¶ 0002.
Regarding claim 19, Alpers teaches:
A computer program product encoded on a non-transitory storage medium, the product comprising non-transitory, computer readable instructions for causing one or more processors to perform operations comprising: (Alpers ¶ 0016-0018: These computer program instructions may also be stored in a computer readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner)
receiving, at a database system, a query for a database table, wherein the query includes a set of parameter values for a set of … predicates; (Alpers FIG. 1, ¶ 0019: In diagram 100, a relational database management system (RDBMS) is provided with a structure query language (SQL) statement 110. The SQL statement 110 includes a predicate 112 (referred to as a join predicate) with a table join 114 and a column of one of the tables constrained to a variable 116)
identifying a query plan for the query that includes a predicate evaluation order for the set of … predicates and a predicate evaluation strategy for each predicate in the set of … predicates; (Alpers shows 'predicate evaluation order' in ¶ 0032-0033, see first ¶ 0032: the needed data for a query can be collected from a database by accessing it in different ways, through different data-structures, and in different orders; see then ¶ 0033: The access path selector 324 selects one of the query plans available to the query optimizer 312 given the estimate (which has estimated selectively of the join predicate). The access path or query plan as used herein represents an ordered set of steps used to access data in a SQL RDBMS (e.g., database repository 330 information); Alpers shows 'predicate evaluation strategy' through its access paths; see Alpers ¶ 0002: Two access paths available to a query optimizer that produces equivalent results include a table scan access path and an index access path; Alpers ¶ 0006: If the estimated quantity of records is greater than a previously determined threshold, the query optimizer optimizes the RDBMS query using a first access path. If the estimated quantity of records is not greater than a previously determined threshold, the query optimizer optimizes the RDBMS query using a second access path. The first access path and the second access path produce functionally equivalent results while having disparate computational speeds to produce the equivalent results; see also Alpers ¶ 0022-0023: the query optimizer executes (142) an access path for the SQL query 110, which is designed to handle a relatively large number of records (in the join predicate 120) [shows the claimed evaluation strategy involving predicates])
determining runtime estimated selectivities by determining a … runtime estimated selectivity for … the set of … predicates based on respective parameter values in the set of parameter values; (Alpers introduces estimated selectivities of predicates as claimed in FIG. 3, ¶ 0010: compute an estimate of records returned for a join predicate to estimate selectively (i.e., inverse of amount of record skew) during query optimization; Alpers ¶ 0032-0033: the query optimizer 312 estimates selectivity across a predicate to pick a better plan than possible if this estimate were not performed … The first time a join occurs on a particular column across two tables, a onetime small overhead estimate for optimization purposes can be performed. The skew estimator 322 performs this estimate, and saves results in the data store 318 for future use by the query optimizer 312. In one embodiment, as records within the respective database repository 330 change over time, skew can change and the estimate for a join predicate can be re-executed [shows being based on 'respective parameter values' as claimed])
determining matching value counts by determining a … matching value count for … the set of … predicates, wherein each matching value count indicates a count of distinct values that match a respective predicate; (Alpers FIG. 1, ¶ 0021-0023, see first ¶ 0021: Diagram 100 estimates the join predicate record return by conducting a query localized to T2 (or to one of the tables of the join predicate) ... A count query 132 is conducted local to table two (T2) where the T2.Col1 is set to the high skew value 127, and where any other local variables (T2.C3) are set to the proper values consistent with the SQL query 110; see also Alpers ¶ 0022: After the SQL count query 132 is executed to estimate the join predicate 120 record quantity, the estimated number of records can be compared against a predefined quantity (e.g., a threshold), as shown by decision block 140. As shown, the count results (from query 132) are compared against a threshold value of fifty)
modifying the query plan with respect to at least one predicate based on at least one of the runtime estimated selectivities or the matching value counts, to generate a modified query plan; and (Alpers FIG. 1, ¶ 0021-0023, see mostly ¶ 0022 showing the claimed 'matching value counts': the count results (from query 132) are compared against a threshold value of fifty. If the estimate is greater than the threshold, the query optimizer executes (142) an access path for the SQL query 110, which is designed to handle a relatively large number of records (in the join predicate 120) in an optimal manner ... If the count result does not exceed the threshold (in decision block 140), the query optimizer 120 can optimize the RDBMS query 110 using a different access path, as shown by block 144; see also Alpers FIG. 2, step 255, ¶ 0027: In step 240, if the quantity of records (estimated per step 235) [also shows 'matching value counts'] is greater than a previously determined threshold, the process can continue to step 245, where the query optimizer can optimize the query per a first access path [shows 'modifying' of a query plan] ... step 250 can execute where the query optimizer selects a second access path (optimized for a relatively low quantity of records resulting from the join predicate) [shows being 'with respect to at least one predicate']; see Alpers ¶ 0033 showing involvement of the claimed 'runtime estimated selectivities': The access path selector 324 selects one of the query plans available to the query optimizer 312 given the estimate (which has estimated selectively of the join predicate))
executing the query, in the database system, according to the modified query plan. (Alpers FIG. 2, step 255, ¶ 0027: In step 255, the RDBMS query can execute using the query optimizer determined access path (access path one or access path two depending on results from step 240 as shown); see Alpers ¶ 0006: a computer program product for skew-sensitive query optimization across join predicates in a relational database management system (RDMBS). In this aspect, a RDBMS query can be received at a query optimizer)
Alpers does not expressly disclose a set of multiple predicates.
Alpers further does not expressly disclose:
determining runtime estimated selectivities by determining a respective runtime estimated selectivity for each predicate in the set of multiple predicates based on respective parameter values in the set of parameter values;
determining matching value counts by determining a respective matching value count for each predicate in the set of multiple predicates,
However, Zhang addresses this by teaching the following.
Zhang teaches “a set of multiple predicates” and further teaches “wherein the query includes a set of parameter values for a set of multiple predicates.” (Zhang pp4-5, ¶ 0052-0054: a query optimizer calculates the selectivity of each of order key predicate separately and subsequently multiplies them together … In SQL Statement Example 1, there are two path identifier predicates (lines 4-5) and three order key predicates (lines 6-8))
Zhang further teaches:
determining runtime estimated selectivities by determining a respective runtime estimated selectivity for each predicate in the set of multiple predicates based on respective parameter values in the set of parameter values; (Zhang pp4-5, ¶ 0058-0061: In SQL Statement Example 1, the selectivity of the predicate at line 4 may be determined using Synopsis Example 1 … the selectivity of predicate P1.pathid=PATHTOID(`/A/B`) is 4/14 … Similarly, the selectivity of the predicate at line 5 (P2.pathid=PATHTOID(`/A/B/D`)) may be determined from Synopsis Example 1. The selectivity of this predicate is 2/14 because there are two (2) elements under the path/A/BID)
determining matching value counts by determining a respective matching value count for each predicate in the set of multiple predicates, (Zhang pp4-5, ¶ 0058-0061: From Synopsis Example 1, it is determined that the number of elements in XML Document Example 1 is 14 (e.g., "count" of element A+"descendants_cnt" of element A). Also from Synopsis Example 1, it is determined that the number of elements under the path/A/B is four (4) (e.g., "count" of element B) ... The selectivity of this predicate is 2/14 because there are two (2) elements under the path/A/BID)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the query plans of Alpers with the query planning of Zhang.
In addition, both of the references (Alpers and Zhang) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as query plan management and execution.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to optimize queries executed by a database system as seen in Zhang ¶ 0002.
Regarding claim 3, Alpers in view of Zhang teaches:
wherein a predicate evaluation strategy for a second predicate comprises an index lookup strategy. (Alpers ABST: A query optimizer receives a relational database management system (RDBMS) query having a join predicate with a join between a first and a second table; Alpers ¶ 0002: Two access paths available to a query optimizer that produces equivalent results include a table scan access path and an index access path; Alpers ¶ 0006: If the estimated quantity of records is greater than a previously determined threshold, the query optimizer optimizes the RDBMS query using a first access path. If the estimated quantity of records is not greater than a previously determined threshold, the query optimizer optimizes the RDBMS query using a second access path. The first access path and the second access path produce functionally equivalent results while having disparate computational speeds to produce the equivalent results; see also Alpers ¶ 0022-0023: the query optimizer executes (142) an access path for the SQL query 110, which is designed to handle a relatively large number of records (in the join predicate 120))
Regarding claim 5, Alpers in view of Zhang teaches all the features with respect to claim 1.
Alpers teaches:
wherein the predicate evaluation order was previously determined during query compilation based at least on compile-time estimated selectivities of predicates in the set of … predicates determined from a previously-received first set of parameter values. (Alpers introduces estimated selectivities of predicates as claimed in FIG. 3, ¶ 0010: compute an estimate of records returned for a join predicate to estimate selectively (i.e., inverse of amount of record skew) during query optimization; Alpers ¶ 0032-0033: the query optimizer 312 estimates selectivity across a predicate to pick a better plan than possible if this estimate were not performed … The first time a join occurs on a particular column across two tables, a onetime small overhead estimate for optimization purposes can be performed. The skew estimator 322 performs this estimate, and saves results in the data store 318 for future use by the query optimizer 312 [shows having been 'previously-received]. In one embodiment, as records within the respective database repository 330 change over time, skew can change and the estimate for a join predicate can be re-executed)
Zhang teaches estimated selectivities of predicates in the set of multiple predicates. (Zhang pp4-5, ¶ 0058-0061: In SQL Statement Example 1, the selectivity of the predicate at line 4 may be determined using Synopsis Example 1 … the selectivity of predicate P1.pathid=PATHTOID(`/A/B`) is 4/14 … Similarly, the selectivity of the predicate at line 5 (P2.pathid=PATHTOID(`/A/B/D`)) may be determined from Synopsis Example 1. The selectivity of this predicate is 2/14 because there are two (2) elements under the path/A/BID)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the query plans of Alpers with the query planning of Zhang.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to optimize queries executed by a database system as seen in Zhang ¶ 0002.
Regarding claim 6, Alpers in view of Zhang teaches all the features with respect to claim 1.
Alpers teaches:
wherein the predicate evaluation order was previously determined during query compilation based at least on estimated worst-case selectivities for predicates in the set of predicates. (Alpers ¶ 0019-0020: a query optimizer 120 is sensitive to skew occurring within a join predicate ... T1 statistics 126 can be available. These statistics 126, as shown, indicate one thousand distinct values for Col1 are present, but that twenty percent of the rows (e.g., records) have a value of “1” for T1.Col1 … Therefore, the query optimizer will assume that each value exists 1/1000 times—since there are 1000 distinct values, and each join is searching for one of those 1000 values)
Zhang teaches selectivities for predicates in the set of multiple predicates. (Zhang pp4-5, ¶ 0058-0061: In SQL Statement Example 1, the selectivity of the predicate at line 4 may be determined using Synopsis Example 1 … the selectivity of predicate P1.pathid=PATHTOID(`/A/B`) is 4/14 … Similarly, the selectivity of the predicate at line 5 (P2.pathid=PATHTOID(`/A/B/D`)) may be determined from Synopsis Example 1. The selectivity of this predicate is 2/14 because there are two (2) elements under the path/A/BID)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the query plans of Alpers with the query planning of Zhang.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to optimize queries executed by a database system as seen in Zhang ¶ 0002.
Regarding claim 7, Alpers in view of Zhang teaches:
wherein modifying the query plan comprises changing the predicate evaluation order based on at least one runtime estimated predicate selectivity being more than a first threshold. (Alpers FIG. 1, ¶ 0021-0023, see mostly ¶ 0022: the count results (from query 132) are compared against a threshold value of fifty. If the estimate is greater than the threshold, the query optimizer executes (142) an access path for the SQL query 110, which is designed to handle a relatively large number of records (in the join predicate 120) in an optimal manner; see also Alpers FIG. 2, step 255, ¶ 0027: In step 240, if the quantity of records (estimated per step 235) is greater than a previously determined threshold, the process can continue to step 245, where the query optimizer can optimize the query per a first access path ... step 250 can execute where the query optimizer selects a second access path (optimized for a relatively low quantity of records resulting from the join predicate); see Alpers ¶ 0032-0033, see first ¶ 0032: the needed data for a query can be collected from a database by accessing it in different ways, through different data-structures, and in different orders; see then ¶ 0033: The access path selector 324 selects one of the query plans available to the query optimizer 312 given the estimate (which has estimated selectively of the join predicate). The access path or query plan as used herein represents an ordered set of steps used to access data in a SQL RDBMS (e.g., database repository 330 information))
Regarding claim 12, Alpers in view of Zhang teaches:
wherein a runtime estimated selectivity of a first predicate corresponds to a percentage of table rows of the database table that are estimated to match the first predicate with respect to a first parameter value in the set of parameters. (Alpers FIG. 3, ¶ 0010: compute an estimate of records returned for a join predicate to estimate selectively (i.e., inverse of amount of record skew) during query optimization; Alpers ¶ 0020: T1 statistics 126 can be available. These statistics 126, as shown, indicate one thousand distinct values for Col1 are present, but that twenty percent of the rows (e.g., records) have a value of “1” for T1.Col1; Alpers ¶ 0022: the relatively high records can result from a high skew (using the value of “1”, which represent 20 percent of the rows from T1.Col1 per statistics 126) which cannot be determined without the estimate from the records returned from the table join 114 further conditioned by a table two column equaling a value (116); Alpers ¶ 0025: In step 220, a value for the join column (e.g., T1.Col1 and/or T2.Col2) can be determined that has a high skew ... in a sales database for a company that sells products in one hundred countries but sells fifty percent of products in the “United States” there would be a high skew. The construction of the able structure of the RDBMS can determine which of the tables is searched for the “high skew” at the join column)
Regarding claim 13, Alpers in view of Zhang teaches:
wherein a runtime estimated selectivity of a first predicate is determined based on locating a first parameter value of the set of parameter values in frequency statistic metadata for the database table. (Alpers ¶ 0019-0020: a query optimizer 120 is sensitive to skew occurring within a join predicate ... T1 statistics 126 can be available. These statistics 126, as shown, indicate one thousand distinct values for Col1 are present, but that twenty percent of the rows (e.g., records) have a value of “1” for T1.Col1 … Therefore, the query optimizer will assume that each value exists 1/1000 times—since there are 1000 distinct values, and each join is searching for one of those 1000 values)
Regarding claim 14, Alpers in view of Zhang teaches:
wherein a runtime estimated selectivity of a first predicate is determined based on sampling the database table and determining how many sampled rows of the database table match the first predicate with respect to a first parameter value of the set of parameters. (Alpers FIG. 1, ¶ 0021-0023, see first ¶ 0021: Diagram 100 estimates the join predicate record return by conducting a query localized to T2 (or to one of the tables of the join predicate) ... A count query 132 is conducted local to table two (T2) where the T2.Col1 is set to the high skew value 127, and where any other local variables (T2.C3) are set to the proper values consistent with the SQL query 110; see also Alpers ¶ 0022: After the SQL count query 132 is executed to estimate the join predicate 120 record quantity, the estimated number of records can be compared against a predefined quantity (e.g., a threshold), as shown by decision block 140. As shown, the count results (from query 132) are compared against a threshold value of fifty; see also Alpers FIG. 2, step 255, ¶ 0027: In step 240, if the quantity of records (estimated per step 235) is greater than a previously determined threshold, the process can continue to step 245)
Regarding claim 15, Alpers in view of Zhang teaches:
wherein a runtime estimated selectivity of a first predicate is determined by: determining that a column referenced in the first predicate stores unique values; and (Alpers ¶ 0010: compute an estimate of records returned for a join predicate to estimate selectively (i.e., inverse of amount of record skew) during query optimization; Alpers ¶ 0025: The construction of the able structure of the RDBMS can determine which of the tables is searched for the “high skew” at the join column. For example, if the RDBMS is in third normal form (3NF), T1.Col1 can be a primary key or a foreign key (values unique) for country code)
determining the runtime estimated selectivity of the first predicate by dividing a value of one by a row count of the database table. (Alpers ¶ 0010: compute an estimate of records returned for a join predicate to estimate selectively (i.e., inverse of amount of record skew) during query optimization; see Alpers ¶ 0003: Record skew is a measurement of asymmetry within a distribution of data in a table. Another related term is “selectivity” which is the measure of the filtering in that a query is highly selective if it results in a minimal number of records being returned and has low selectively if it results in a large quantity of records being returned)
Claims 2, 8; 18; and 20 are rejected under 35 U.S.C. 103 as being unpatentable over Alpers in view of Zhang in further view of Merker et al., U.S. Patent No. 11,016,973 (shares assignee with instant application and inventor with later reference Horn; published May 25, 2021; hereinafter Merker).
Regarding claims 2, 18, and 20, Alpers in view of Zhang teaches all the features with respect to claims 1, 17, and 19 above respectively including wherein a predicate evaluation strategy for a first predicate comprises a … strategy.
Alpers in view of Zhang does not expressly disclose a data vector scan strategy.
However, Merker addresses this by teaching a data vector scan strategy. (Merker col. 9, lines 45-61: the table adapter 250/252 may each include one or more of the following types of metadata to enable access to, and/or, preparation of a table object for the execution engine … one or more query execution hints about execution strategies that may be beneficial for the table (e.g., for a given table whether a full indexvector scan or a single docid lookup is optimum))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the access paths and query plans of Alpers as modified with the query plan execution of Merker.
In addition, both of the references (Alpers as modified and Merker) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as query plan management and execution.
Motivation to do so would be to improve the functioning of Alpers as modified and its various query plan strategies with the functioning of similar reference Merker also involving query strategies but further including metadata to enable access to and/or preparation of data for query execution including execution strategies beneficial for the table (Merker col. 9, lines 45-61).
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to reduce or eliminate the need for specialized execution engines for each type of database as seen in Merker col. 3, lines 61-67.
Regarding claim 8, Alpers in view of Zhang teaches all the features with respect to claim 1 above including:
wherein modifying the query plan comprises changing a predicate evaluation strategy for a first predicate from an index lookup strategy to a … strategy based on a matching value count for the first predicate being more than a second threshold. (Alpers FIG. 1, ¶ 0021-0023, see mostly ¶ 0022: the count results (from query 132) are compared against a threshold value of fifty. If the estimate is greater than the threshold, the query optimizer executes (142) an access path for the SQL query 110, which is designed to handle a relatively large number of records (in the join predicate 120) in an optimal manner; see also Alpers FIG. 2, step 255, ¶ 0027: In step 240, if the quantity of records (estimated per step 235) is greater than a previously determined threshold, the process can continue to step 245, where the query optimizer can optimize the query per a first access path ... step 250 can execute where the query optimizer selects a second access path (optimized for a relatively low quantity of records resulting from the join predicate); see Alpers ¶ 0033: The access path selector 324 selects one of the query plans available to the query optimizer 312 given the estimate (which has estimated selectively of the join predicate))
Alpers teaches an index lookup strategy. (Alpers ¶ 0001-0002, see first ¶ 0001: database query optimization and, more particularly, to skew sensitive estimating of record cardinality of a join predicate for optimizer access path (e.g., query plan) selection; see then Alpers ¶ 0002: Two access paths available to a query optimizer that produces equivalent results include a table scan access path and an index access path. In a table scan, the query optimizer sequentially reads all rows of a table and compares each row with the search criteria in the WHERE clause, which is called a predicate in a SQL query)
Alpers in view of Zhang does not expressly disclose a data vector scan strategy.
However, Merker addresses this by teaching a data vector scan strategy. (Merker col. 9, lines 45-61: the table adapter 250/252 may each include one or more of the following types of metadata to enable access to, and/or, preparation of a table object for the execution engine … one or more query execution hints about execution strategies that may be beneficial for the table (e.g., for a given table whether a full indexvector scan or a single docid lookup is optimum))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the access paths and query plans of Alpers with the query plan execution of Merker.
In addition, both of the references (Alpers and Merker) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as query plan management and execution.
Motivation to do so would be to improve the functioning of Alpers and its various query plan strategies with the functioning of similar reference Merker also involving query strategies but further including metadata to enable access to and/or preparation of data for query execution including execution strategies beneficial for the table (Merker col. 9, lines 45-61).
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to reduce or eliminate the need for specialized execution engines for each type of database as seen in Merker col. 3, lines 61-67.
Regarding claim 9, Alpers in view of Zhang and Merker teaches all the features with respect to claim 8 above including:
wherein the predicate evaluation strategy for the first predicate is changed from the index lookup strategy to the … strategy to avoid multiple index lookups of multiple different values. (Alpers ¶ 0001-0002: Two access paths available to a query optimizer that produces equivalent results include a table scan access path and an index access path. In a table scan, the query optimizer sequentially reads all rows of a table and compares each row with the search criteria in the WHERE clause, which is called a predicate in a SQL query ... Generally, when a number of records being considered is high, the table scan access path is faster)
Merker teaches the data vector scan strategy. (Merker col. 9, lines 45-61: the table adapter 250/252 may each include one or more of the following types of metadata to enable access to, and/or, preparation of a table object for the execution engine … one or more query execution hints about execution strategies that may be beneficial for the table (e.g., for a given table whether a full indexvector scan or a single docid lookup is optimum))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the access paths and query plans of Alpers as modified with the query plan execution of Merker.
Motivation to do so would be to improve the functioning of Alpers as modified and its various query plan strategies with the functioning of similar reference Merker also involving query strategies but further including metadata to enable access to and/or preparation of data for query execution including execution strategies beneficial for the table (Merker col. 9, lines 45-61).
Claim 10 is rejected under 35 U.S.C. 103 as being unpatentable over Alpers in view of Zhang in further view of Merker in further view of Cain et al., U.S. Patent Application Publication No. 2009/0182720 (hereinafter Cain).
Regarding claim 10, Alpers in view of Zhang in further view of Merker teaches all the features with respect to claim 8 above including:
wherein the predicate evaluation strategy for the first predicate is changed from the index lookup strategy to the … strategy… (Alpers FIG. 1, ¶ 0021-0023, see mostly ¶ 0022: the count results (from query 132) are compared against a threshold value of fifty. If the estimate is greater than the threshold, the query optimizer executes (142) an access path for the SQL query 110, which is designed to handle a relatively large number of records (in the join predicate 120) in an optimal manner; see also Alpers FIG. 2, step 255, ¶ 0027: In step 240, if the quantity of records (estimated per step 235) is greater than a previously determined threshold, the process can continue to step 245, where the query optimizer can optimize the query per a first access path ... step 250 can execute where the query optimizer selects a second access path (optimized for a relatively low quantity of records resulting from the join predicate); see Alpers ¶ 0033: The access path selector 324 selects one of the query plans available to the query optimizer 312 given the estimate (which has estimated selectively of the join predicate))
Alpers in view of Zhang and Merker does not expressly disclose doing so to enable data vector scan parallelism.
However, Cain teaches changing strategies “to enable data vector scan parallelism.” (Cain ¶ 0004: encoded vector index ("EVI"). An EVI is a data structure that is made up of two primary components: a symbol table and a vector … Because of their compact size and relative simplicity, EVIs provide for faster scans of a table that may also be processed in parallel; Cain shows involvement of predicates in at least ¶ 0008: Determining if a predicate structure is a good candidate for a symbol table only data structure, for some embodiments, includes analyzing a grouping, ordering, and distincting of the database query and system generated lookahead predicates. Generation of the symbol table only data structure may be triggered)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the access paths and query plans of Alpers as modified with the database query optimization of Cain.
In addition, both of the references (Alpers as modified and Cain) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as query management and execution.
Motivation to do so would be to improve the functioning of Alpers as modified and its various query plan strategies with the functioning of similar reference Cain also involving query strategies but further including vector techniques and symbol techniques.
Claim 11 is rejected under 35 U.S.C. 103 as being unpatentable over Alpers in view of Zhang in further view of Merker in further view of Paulley, U.S. Patent Application Publication No. 2002/0116357 (hereinafter Paulley).
Regarding claim 11, Alpers in view of Zhang teaches all the features with respect to claim 1 above including:
wherein modifying the query plan comprises changing a predicate evaluation strategy for a first predicate from an index lookup strategy to a … strategy based on the first predicate … in the predicate evaluation order. (Alpers ¶ 0032-0033, see first ¶ 0032: the needed data for a query can be collected from a database by accessing it in different ways, through different data-structures, and in different orders; see then Alpers ¶ 0033: The access path selector 324 selects one of the query plans available to the query optimizer 312 given the estimate (which has estimated selectively of the join predicate). The access path or query plan as used herein represents an ordered set of steps used to access data in a SQL RDBMS (e.g., database repository 330 information); Alpers FIG. 1, ¶ 0021-0023, see mostly ¶ 0022: the query optimizer 120 can optimize the RDBMS query 110 using a different access path, as shown by block 144; see also Alpers FIG. 2, step 255, ¶ 0027: step 250 can execute where the query optimizer selects a second access path (optimized for a relatively low quantity of records resulting from the join predicate))
Alpers in view of Zhang does not expressly disclose the data vector scan strategy.
Alpers in view of Zhang further does not expressly disclose the first predicate no longer being positioned first.
However, Merker addresses this by teaching data vector scan strategy. (Merker col. 9, lines 45-61: the table adapter 250/252 may each include one or more of the following types of metadata to enable access to, and/or, preparation of a table object for the execution engine … one or more query execution hints about execution strategies that may be beneficial for the table (e.g., for a given table whether a full indexvector scan or a single docid lookup is optimum))
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the access paths and query plans of Alpers as modified with the query plan execution of Merker.
In addition, both of the references (Alpers as modified and Merker) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as query plan management and execution.
Motivation to do so would be to improve the functioning of Alpers as modified and its various query plan strategies with the functioning of similar reference Merker also involving query strategies but further including metadata to enable access to and/or preparation of data for query execution including execution strategies beneficial for the table (Merker col. 9, lines 45-61).
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to reduce or eliminate the need for specialized execution engines for each type of database as seen in Merker col. 3, lines 61-67.
Alpers in view of Zhang and Merker does not expressly disclose the first predicate no longer being positioned first.
However, Paulley addresses this by teaching the first predicate no longer being positioned first in the predicate evaluation order. (Paulley c1: determining a strategy cost for satisfying the query using a query access plan that employs said initial join order; starting from the innermost positions of the join order and proceeding to be outermost position of the join order, evaluating other candidate join orders by swapping ordering of tables at a given position with those at subsequent positions and thereafter determining the cost strategy for that join order; see relatedly support in Paulley ¶ 0061 describing swapping operands and ¶ 0124 describing inputs associated with a strategy position)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the predicates and query plans and strategies of Alpers as modified with the predicates and the query plan and strategies of Paulley.
In addition, both of the references (Alpers as modified and Paulley) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as query predicate management and execution.
Motivation to do so would be to improve the functioning of Alpers as modified and its query predicate management with the functioning of similar reference Paulley also involving query predicates but further including determining costs for particular join orders.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to improv the process of accessing and processing databases from memory constrained (e.g., portable) devices as seen in Paulley ¶ 0047.
Claim 13 is rejected under 35 U.S.C. 103 as being unpatentable over Alpers in view of Zhang and Su et al., U.S. Patent Application Publication No. 2014/0095475 (hereinafter Su).
Regarding claim 13, Alpers and Zhang teaches all the features with respect to claim 1 above including:
wherein a runtime estimated selectivity of a first predicate is determined based on locating a first parameter value of the set of parameter values in … statistic metadata for the database table. (Zhang ¶ 0058: SQL Statement Example 1, the selectivity of the predicate at line 4 may be determined...; see then Zhang ¶ 0061: Each of these selectivity values may be calculated using statistics (e.g., from Synopsis Example 1) on the PATHID and ORDER_KEY columns)
Alpers and Zhang does not expressly disclose frequency statistic metadata.
However, Su addresses this by teaching determin[ing] based on locating a first parameter value of the set of parameter values in frequency statistic metadata for the database table. (Su FIG. 6A, ¶ 0187-0196; see ¶ 0187: The accuracy of a histogram is important for selectivity estimation. If a query optimizer checks a histogram to determine a selectivity of a particular value in a query and the histogram is not accurate regarding the frequency of the particular value, then the query optimizer might select a suboptimal execution plan; see ¶ 0188: One type of histogram is a "frequency" histogram that indicates, for each distinct value in a set, a frequency of that distinct value)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the query optimizer and selectivity determination of Alpers as modified with the selectivity histograms of Su.
In addition, both of the references (Alpers as modified and Su) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as selectivity determination.
Motivation to do so would be to improve the functioning of Alpers as modified and its query optimizer deriving statistics associated with tables to determine cost with the functioning of similar reference Su also deriving statistics associated with tables but with added histogram techniques.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to gather information for automatic reoptimization of queries as seen in Su ¶ 0023.
Claim 16 is rejected under 35 U.S.C. 103 as being unpatentable over Alpers in view of Zhang in further view of Horn et al., U.S. Patent Application Publication No. 2020/0320048 (shares assignee with instant application and inventor with Merker; hereinafter Horn).
Regarding claim 16, Alpers in view of Zhang teaches all the features with respect to claim 1 above including the set of multiple predicates.
Alpers in view of Zhang does not expressly disclose wherein the … predicates are included in a conjunction.
However, Horn addresses this by teaching:
wherein the set of … predicates are included in a conjunction. (Horn ¶ 0042-0045: a filter evaluation strategy may be selected whenever a query includes conjunction (AND) operator between at least two predicates … predicates in a conjunction may be ordered by selectivity, and hence, for each predicate a cost function may be determined using any of the above filter evaluation strategies and most cost-effective strategy may be selected for each such predicate)
It would have been obvious to one of ordinary skill in the art before the effective filing date of the claimed invention to combine the functioning of the query cost determination of Alpers as modified with the query cost determination of Horn.
In addition, both of the references (Alpers as modified and Horn) disclose features that are directed to analogous art, and they are directed to the same field of endeavor, such as query plan cost calculations.
Motivation to do so would be to improve the functioning of Alpers as modified estimating costs to optimize queries with the functioning of similar reference Horn also analyzing queries and estimating costs but with its various evaluation strategies and determination thereof.
Motivation to do so would also be the teaching, suggestion, or motivation for a person of ordinary skill in the art to reduce or eliminate the need for specialized execution engines for each type of database as seen in Horn ¶ 0020
Conclusion
The prior art made of record and not relied upon is considered pertinent to applicant's disclosure.
Faunce et al., U.S. Patent Application Publication No. 2008/0235181, "Query Expression Evaluation Using Sample Based Projected Selectivity"; see Faunce FIG. 4, ¶ 0053-0058 describing assigning a selectivity factor to each predicate, then determining a selectivity rating for each intersection, relevant at least to the independent claim limitations involving determining selectivities associated with predicates in a set of multiple predicates.
Applicant's amendment necessitated the new ground(s) of rejection presented in this Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 706.07(a). Applicant is reminded of the extension of time policy as set forth in 37 CFR 1.136(a).
A shortened statutory period for reply to this final action is set to expire THREE MONTHS from the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the mailing date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH shortened statutory period, then the shortened statutory period will expire on the date the advisory action is mailed, and any nonprovisional extension fee (37 CFR 1.17(a)) pursuant to 37 CFR 1.136(a) will be calculated from the mailing date of the advisory action. In no event, however, will the statutory period for reply expire later than SIX MONTHS from the mailing date of this final action.
Any inquiry concerning this communication or earlier communications from the examiner should be directed to JEDIDIAH P FERRER whose telephone number is (571)270-7695. The examiner can normally be reached Monday-Friday 12:00pm-8:00pm.
Examiner interviews are available via telephone, in-person, and video conferencing using a USPTO supplied web-based collaboration tool. To schedule an interview, applicant is encouraged to use the USPTO Automated Interview Request (AIR) at http://www.uspto.gov/interviewpractice.
If attempts to reach the examiner by telephone are unsuccessful, the examiner’s supervisor, Kavita Stanley can be reached at (571)272-8352. The fax phone number for the organization where this application or proceeding is assigned is 571-273-8300.
Information regarding the status of published or unpublished applications may be obtained from Patent Center. Unpublished application information in Patent Center is available to registered users. To file and manage patent submissions in Patent Center, visit: https://patentcenter.uspto.gov. Visit https://www.uspto.gov/patents/apply/patent-center for more information about Patent Center and https://www.uspto.gov/patents/docx for information about filing in DOCX format. For additional questions, contact the Electronic Business Center (EBC) at 866-217-9197 (toll-free). If you would like assistance from a USPTO Customer Service Representative, call 800-786-9199 (IN USA OR CANADA) or 571-272-1000.
/J.P.F/Examiner, Art Unit 2153 December 19, 2025
/KRIS E MACKES/Primary Examiner, Art Unit 2153