The present invention relates to processing queries in a multi-node database system. Specifically, the present invention relates to retrieving data from temporary tables to process multi-stage queries.
In a clustered database system, multiple “nodes” may have access to the same on-disk copy of a database. Typically, each node is a computing device with its own local memory and processors that are running one or more database instances. The database server instances on each of the nodes may receive queries to access the data. A query coordinator may assign work to be performed for the query among multiple slave processes running on the nodes in the database system, in order to process the query in parallel.
A complex query may be executed in multiple stages. During execution of the query, results generated by a stage may be used by another, subsequent stage. These results are temporarily stored in a table referred to herein as a “cursor duration temporary table.” When a database system receives a query, it generates an execution plan for executing the query. If cursor duration temporary tables are required, then execution plan operations are written to refer to one or more temporary tables. A temporary table may be stored on a shared disk or in memory of one or more nodes so that they can be accessed in later stages.
Various approaches for storing cursor duration temporary tables, or portions thereof, into volatile memory to speed up query processing are described in U.S. patent application Ser. No. 15/268,519, entitled “In-Memory Cursor Duration Temp Tables,” filed Sep. 16, 2016, referred to herein as the “In-Memory” application, the contents of which are incorporated herein in its entirety.
According to the approaches described in the In-Memory application, a portion of memory in each node of a clustered database system is allocated for storing in-memory cursor duration temporary tables. A slave process may be assigned one or more memory segments from the portion of memory for writing temporary table data. Any slave process running on the same node may read from the one or more memory segments. Nodes in the cluster may have access to one or more disks, which may be used to store temporary table data that do not fit in memory. One or more disk segments may be assigned to a slave process for writing excess data. Any slave process running on the same node may read from the one or more disk segments.
Some queries include iterative operations that reference results stored for prior iterations, while the final output of the query references results from multiple iterations. Results from all iterations may be stored in a single temporary table, with data indicating iteration values associated with each respective iteration. When data from a particular iteration is requested, the temporary table is scanned and a predicate is applied to find rows with the associated iteration value. However, this approach results in slower processing speeds since all the data from previous iterations are scanned, even ones that are not required for the operation.
The approaches described in this section are approaches that could be pursued, but not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated, it should not be assumed that any of the approaches described in this section qualify as prior art merely by virtue of their inclusion in this section.
In the drawings:
In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, that the present invention may be practiced without these specific details. In other instances, well-known structures and devices are shown in block diagram form in order to avoid unnecessarily obscuring the present invention.
General Overview
Techniques are presented herein for storing iterations of an iterative query operation with the memory segments and disk segments in the nodes used for writing to cursor duration temporary tables
According to an embodiment, a portion of memory in each node of a clustered database system is allocated for storing in-memory cursor duration temporary tables. Each portion of memory may be divided into one or more memory segments. When data for an iteration is written to a memory segment, an iteration value for the iteration is associated with the memory segment.
According to an embodiment, each node has access to a disk, where a portion of the disk is used for storing in-memory cursor duration temporary tables. Each disk portion may be divided into one or more disk segments. If data for an iteration does not fit in a memory segment, the excess data may be written to a disk segment. If data for an iteration is stored in a disk segment, the iteration value for the iteration is associated with the disk segment.
When an iteration is executed by the database system, it may require data from one or more previous iterations. In an embodiment, prior to reading data from a memory segment, iteration values associated with the memory segment are checked to determine whether the memory segment contains data for the one or more previous iterations. If the memory segment does not contain relevant data, then the database system does not have to read from that memory segment. If any disk segments were used to store data, the iteration values associated with the disk segments are checked to determine whether any disk segments contain data for the one or more previous iterations. If a disk segment does not contain relevant data, then the database system does not have to read from the disk segment.
In Memory Cursor Duration Temp Tables
Various database languages, such as SQL, support special-purpose constructs referred to herein as “cursors.” During compilation of a query statement, the database server may perform a significant amount of preliminary work for the statement, such as parsing, semantic analysis, and query plan generation. A cursor stores much of the preliminary work. One set of information stored in a cursor includes the execution plan for performing the operations specified by the SQL statement.
An execution plan defines operations to be performed to execute a query and an order for performing the operations, known as plan operations. When a database instance receives a query, a query coordinator formulates a query execution plan for executing the query. The execution plan may specify that one or more plan operations are to be processed in parallel by one or more slave processes.
A plan operation may generate output that is stored in a temporary table for use during execution of another plan operation. If a query execution plan requires the use of temporary tables, one or more temporary tables are created and plan operations are written to reference the temporary tables.
In-memory cursor duration temporary tables refer to temporary tables that are stored primarily in local memory with excess data written to temporary disk segments. In a clustered database system, a portion of local RAM memory from each node in the cluster may be used to store in-memory temporary tables. The in-memory temporary may be divided into portions and each portion is stored in local memory of a node in the cluster.
System Overview
Nodes 102, 112, and 122 have access to the same database 160. For the purpose of illustration, database 160 is shown as stored on a single shared disk 150, but in alternative embodiments may be spread across multiple disks to which each of nodes 102, 112, and 122 have access.
Nodes 102, 112, and 122 respectively have one or more processors 108, 118, and 128, and local RAM memory 104, 114, and 124. In addition, nodes 102, 112, and 122 are respectively executing database server instances 106, 116, and 126. While in the illustrated embodiment each node is executing a single database server instance, in alternative embodiments, a single node may execute more than one database server instance.
A portion of the local memory for each node may be used to store in-memory CDT data.
Memory portions 204, 214, and 224 may be directly accessed by processes running on the respective nodes. For example, memory portion 204 may be used by a process running on processor 108. Similarly, memory portion 214 may be used by a process running on processor 118.
In an embodiment, memory portion 204, 214, and 224 are further divided into a plurality of memory segments. Each memory segment may be assigned to a process running on the node the memory portion belongs to. Each node may have a different number of memory segments and the memory segments may be of different sizes. In the present example, memory portion 204 comprises memory segments 204a, 204b, and 204c; memory portion 214 comprises memory segments 214a, 214b, and 214c; and memory portion 224 comprises memory segments 224a, 224b, and 224c.
In an embodiment, one or more portions of shared disk 150 are also used to store in-memory CDT data. The portions may be allocated when the database system starts, or may be allocated on an as-needed basis during query processing.
The one or more disk portions may be further divided into a plurality of disk segments. In an embodiment, a disk segment is allocated and assigned to a process writing in-memory CDT data when the CDT data requires more space than an assigned memory segment can hold. In another embodiment, each process writing in-memory CDT data is assigned a disk segment at the start of writing in-memory CDT data, regardless of the size of the CDT data.
Iterative Operations
A query may include one or more iterative database query operations. As used herein, an iterative operation refers to a query operation that is executed a number of times, such as a recursive operation. Certain computational tasks are performed using recursive operations, such as frequent item set determination and graph traversal.
In the illustrated example, query 300 includes a recursive WITH clause “rw.” As used herein, a WITH clause is a database statement that provides an alias for a sub-query comprising one or more database operations. For example, if a query includes a particular sub-query multiple times, a user may define a WITH clause that includes the sub-query. The query may be written to reference the WITH clause rather than repeat the contents of the sub-query multiple times. In an embodiment, an execution plan for a query that includes a WITH clause may define and create a temporary table for the WITH clause. Plan operations that include the WITH clause may refer to the temporary table.
A recursive WITH clause is a WITH clause that references itself. In an embodiment, an execution plan for a query that includes a recursive WITH clause may define and create a temporary table for the recursive WITH clause. Each iteration of the recursive WITH clause uses the same temporary table to load and store data.
Based on the components of query 200, the query coordinator generates an execution plan for executing the query. In an embodiment, the execution plan for a query that includes an iterative operation comprises at least three stages: an initialization stage, an iterative stage, and a finalization stage.
The initialization stage executes a single time. The initialization stage may include loading data to be used during execution of subsequent stages. In the present example, the initialization stage for query 200, indicated by section 310, includes scanning table T, selecting rows where the “fid” column equals 1, and storing the results in a temporary table.
The iterative stage includes one or more iterative operations. The iterative stage may end after a particular number of iterations or when a particular exit condition is reached. In an embodiment, the execution plan indicates that the iterative operations repeat, but may not indicate the number of iterations. The number of times an iterative operation iterates may not be determined until execution of the iterative stage completes.
In the present example, the iterative stage, indicated by section 320, includes executing the recursive WITH clause “rw” and storing the results for each iteration in the temporary table. At the end of an iteration, any exit conditions are checked to determine whether to execute another iteration or to proceed to the finalization stage. In the present example, clause “rw” repeats while T.fid equals rw.TID or while the variable “count” is less than 10.
In an embodiment, the initialization stage and each iteration of the iterative stage is associated with an iteration value. The iteration value may be a number, string, or some other value that indicates a current iteration. For example, the initialization stage may be considered the initial iteration and is associated with an iteration value of 0. The first iteration of the iteration stage is then associated with an iteration value of 1 and the second iteration of the iteration stage associated with an iteration value of 2, such that the Nth iteration of the iteration stage is associated with iteration value of N.
An iteration may require data that was generated and stored for one or more prior iterations. For example, iteration N may require data from the last iteration N−1, some other prior iteration K, or a set of iterations, such as iterations L through N−1. In an embodiment, row of the temporary table are associated with a respective iteration value. Storing data in the temporary table may include storing the iteration value associated with an iteration. Techniques for associating data in a temporary table with one or more iteration values is discussed in further detail below.
As illustrated in
SELECT rw.fid, T.tid, rw.cost+T.cost, rw.count+1
FROM T, rw
Thus, each iteration of “rw” requires data (rw.fid, rw.cost, and rw.count) generated by the previous iteration of “rw.” In other words, for an iteration N of clause “rw,” the iteration requires data stored for iteration N−1. Rows generated by an iteration of “rw” may be stored with an iteration value that indicates its iteration number.
The finalization stage may include additional query operations on data stored in the temporary table and outputting a set of one or more results. In the present example, the finalization stage includes grouping all rows of the temporary table by the “fid” and “tid” columns, aggregating the “count” and “cost” columns for each group, and outputting the results.
Although the present example is described using recursive WITH, the techniques described herein can be used with other recursive operations, such as frequent item sets and connect by, or by non-iterative operations that request results generated by other query operations.
Associating Data with Iteration Values
If a row is associated with an iteration value, then data stored in a temporary table for that row may be associated with the iteration value. As discussed in the In-Memory application, data for a temporary table is stored in one or more memory portions and/or one or more disk portions. In an embodiment, a memory portion and a disk portions may be further divided into one or more memory segments and one or more disk segments, respectively. For the purpose of illustrating a clear example, techniques are described with reference to segments, but may be used with portions, blocks, or any other level of granularity.
In an embodiment, each memory segment or disk segment is associated with one or more iteration values of the data stored in each respective memory portion or disk portion. If a segment stores data for a single iteration, then it is associated with a single iteration value. If a segment stores data for multiple iterations, then it is associated with multiple iteration values. For example, if a memory segment stores data from iteration 4 and iteration 5, then the memory segment is associated with the iteration values for iteration 4 and iteration 5. If a memory segment only stores data for iteration 2, then it is associated only with the iteration value for iteration 2. A segment may be associated with one or more iteration values, and an iteration value may be associated with one or more segments. The number of iterations associated with a segment may vary depending on the size and number of rows for an iteration and the size of the segment.
In an embodiment, the database system stores a data structure that indicates segment information for a temporary table. The data structure may include information about the number of segments, the size and location of each segment, and one or more iteration values associated with each portion. In an embodiment, the database system stores a data structure for memory segments and a separate data structure for disk segments. In other embodiments, the data structure indicates both disk and memory segments.
In an embodiment, after a slave process writes data to a segment, it indicates in the data structure a segment ID, an iteration value to associate with the segment, and the start and end location for the iteration value. For example, the data structure may indicate the starting block number and an ending block number within a segment for a set of data blocks.
Pruning Using Iteration Values
An iteration may require data stored in the temporary table from one or more previous iterations. Rather than reading the entire temporary table and filtering rows from the results, the temporary table may be pruned so that only the data for the relevant iteration(s) is read. Prior to reading a row from the temporary table, the database system determines if the iteration value associated with the row matches an iteration value associated with one or more requested iterations.
In an embodiment, each memory segment or disk segment is associated with one or more iteration values. Prior to reading data from a segment, the database system determines if at least one of the one or more iteration values of the segment is an iteration value associated with a requested iteration. In an embodiment, the data structure indicating segment information is used to determine which segments include data associated with the one or more requested iteration values.
In an embodiment, the slave processes each select a particular memory segment or disk segment to read. A slave process may select a segment to read based on the segment information stored in the data structure. In an embodiment, a slave process determines, based on one or more iteration value associated with a segment in the data structure, whether the segment includes data for a desired iteration. If the segment contains data for a desired iteration, the slave process reads from the segment.
In an embodiment, the data structure indicates the start and end location within a segment that stores data for an iteration. A slave process may select a segment and read only from the portion of the segment that stores data for a requested iteration. For example, if blocks 150 to 2000 of a segment store data for a requested iteration, then a slave process may generate a work granule that includes reading from block 150 to block 950. The slave process may indicate the location it read to. Another slave process may generate a work granule that reads from block 951 to block 2000.
In an embodiment, the database system also generates and stores a column in the temporary table indicating an iteration value for a row. After data is read from the temporary table, the rows may be filtered based on the iteration value column. If a row that is not associated with the requested iteration is read, then it will still be filtered out. In an embodiment, the iteration value stored in the column may be based on the iteration value stored in the data structure, but may use a different set of values or a different data type. For example, the iteration value stored in the column may be an integer from 0 to N, while the iteration value stored in the data structure may be a string from “itr_1” to “itr_(N+1).”
DBMS Overview
A DBMS manages one or more databases. A DBMS may comprise one or more database servers. A database comprises database data and a database dictionary that are stored on a persistent memory mechanism, such as a set of hard disks. Database data may be stored in one or more data containers. Each container contains records. The data within each record is organized into one or more fields. In relational DBMS's, the data containers are referred to as tables, the records are referred to as rows, and the fields are referred to as columns. In object-oriented databases, the data containers are referred to as object classes, the records are referred to as objects, and the fields are referred to as attributes. Other database architectures may use other terminology.
Users interact with a database server of a DBMS by submitting to the database server commands that cause the database server to perform operations on data stored in a database, as well as other kinds of operations. A database command may be in the form of a database statement that conforms to a database language. A database language for expressing the database commands is the Structured Query Language (SQL). There are many different versions of SQL, some versions are standard and some proprietary, and there are a variety of extensions. Data definition language commands are issued to a database server to create or configure database objects, such as tables, views, or complex data types. DDL commands are used to configure a database server for a particular hardware environment, to configure computer resource usage of the database server, as well as other operating aspects of the database server.
A multi-node database management system is made up of interconnected nodes that share access to the same database or databases. Typically, the nodes are database server hosts interconnected via a network and share access, in varying degrees, to shared storage, e.g. shared access to a set of disk drives and data blocks stored thereon. Each node in a multi-node database system hosts a database server. A server, such as a database server, is a combination of software and an allocation of computational resources, such as memory, a node, and processes on the node for executing the integrated software components on a processor, the combination of the software and computational resources being dedicated to performing a particular function on behalf of one or more clients.
Resources from multiple nodes in a multi-node database system can be allocated to running a particular database server's software. Each combination of the software and allocation of resources from a node is a server that is referred to as a “server instance” or “instance.” A database server may comprise multiple database instances, some or all of which are running on separate computers, including separate server blades.
The term process refers to a computer system process, which is described below in the HARDWARE OVERVIEW. Processes that comprise a database server run under the control of the database server (i.e. can be created or terminated by the database server) and perform various database server functions. Such processes are referred to herein as database server processes. Database server processors include listeners, garbage collectors, log writers, “server processes” for database sessions for executing database commands issued by database clients (including processes executing within shared sessions), and recovery processes.
Data Blocks
A data block is a unit of persistent storage and is used by a database server to store one or row more database rows, or portions of rows, including one or more columns of a row. When rows are read from persistent storage, a data block containing the row is copied into a data block buffer in RAM and/or main memory of a database server. A data block usually contains multiple rows, and data block metadata describing the contents of the data block. Metadata includes control and formatting information, such as offsets to sequences of bytes representing rows or other data structures, and a list of transactions affecting a row.
A data block is referred to as being atomic because, at least in part, a data block is the smallest unit of database data a database server may request from a persistent storage device. For example, when a database server seeks a row that is stored in a data block, the data block may only read the row from a persistent storage device by reading in the entire data block.
A data block is associated with a data block address that uniquely identifies the data block and the data block's storage location within a storage device. A database server may request from a storage device a data block by data block address, or even by primary block address ranges of data blocks.
Hardware Overview
According to one embodiment, the techniques described herein are implemented by one or more special-purpose computing devices. The special-purpose computing devices may be hard-wired to perform the techniques, or may include digital electronic devices such as one or more application-specific integrated circuits (ASICs) or field programmable gate arrays (FPGAs) that are persistently programmed to perform the techniques, or may include one or more general purpose hardware processors programmed to perform the techniques pursuant to program instructions in firmware, memory, other storage, or a combination. Such special-purpose computing devices may also combine custom hard-wired logic, ASICs, or FPGAs with custom programming to accomplish the techniques. The special-purpose computing devices may be desktop computer systems, portable computer systems, handheld devices, networking devices or any other device that incorporates hard-wired and/or program logic to implement the techniques.
For example,
Computer system 400 also includes a main memory 406, such as a random access memory (RAM) or other dynamic storage device, coupled to bus 402 for storing information and instructions to be executed by processor 404. Main memory 406 also may be used for storing temporary variables or other intermediate information during execution of instructions to be executed by processor 404. Such instructions, when stored in non-transitory storage media accessible to processor 404, render computer system 400 into a special-purpose machine that is customized to perform the operations specified in the instructions.
Computer system 400 further includes a read only memory (ROM) 408 or other static storage device coupled to bus 402 for storing static information and instructions for processor 404. A storage device 410, such as a magnetic disk, optical disk, or solid-state drive is provided and coupled to bus 402 for storing information and instructions.
Computer system 400 may be coupled via bus 402 to a display 412, such as a cathode ray tube (CRT), for displaying information to a computer user. An input device 414, including alphanumeric and other keys, is coupled to bus 402 for communicating information and command selections to processor 404. Another type of user input device is cursor control 416, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 404 and for controlling cursor movement on display 412. This input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the device to specify positions in a plane.
Computer system 400 may implement the techniques described herein using customized hard-wired logic, one or more ASICs or FPGAs, firmware and/or program logic which in combination with the computer system causes or programs computer system 400 to be a special-purpose machine. According to one embodiment, the techniques herein are performed by computer system 400 in response to processor 404 executing one or more sequences of one or more instructions contained in main memory 406. Such instructions may be read into main memory 406 from another storage medium, such as storage device 410. Execution of the sequences of instructions contained in main memory 406 causes processor 404 to perform the process steps described herein. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions.
The term “storage media” as used herein refers to any non-transitory media that store data and/or instructions that cause a machine to operate in a specific fashion. Such storage media may comprise non-volatile media and/or volatile media. Non-volatile media includes, for example, optical disks, magnetic disks, or solid-state drives, such as storage device 410. Volatile media includes dynamic memory, such as main memory 406. Common forms of storage media include, for example, a floppy disk, a flexible disk, hard disk, solid-state drive, magnetic tape, or any other magnetic data storage medium, a CD-ROM, any other optical data storage medium, any physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FLASH-EPROM, NVRAM, any other memory chip or cartridge.
Storage media is distinct from but may be used in conjunction with transmission media. Transmission media participates in transferring information between storage media. For example, transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 402. Transmission media can also take the form of acoustic or light waves, such as those generated during radio-wave and infra-red data communications.
Various forms of media may be involved in carrying one or more sequences of one or more instructions to processor 404 for execution. For example, the instructions may initially be carried on a magnetic disk or solid-state drive of a remote computer. The remote computer can load the instructions into its dynamic memory and send the instructions over a telephone line using a modem. A modem local to computer system 400 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector can receive the data carried in the infra-red signal and appropriate circuitry can place the data on bus 402. Bus 402 carries the data to main memory 406, from which processor 404 retrieves and executes the instructions. The instructions received by main memory 406 may optionally be stored on storage device 410 either before or after execution by processor 404.
Computer system 400 also includes a communication interface 418 coupled to bus 402. Communication interface 418 provides a two-way data communication coupling to a network link 420 that is connected to a local network 422. For example, communication interface 418 may be an integrated services digital network (ISDN) card, cable modem, satellite modem, or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 418 may be a local area network (LAN) card to provide a data communication connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 418 sends and receives electrical, electromagnetic or optical signals that carry digital data streams representing various types of information.
Network link 420 typically provides data communication through one or more networks to other data devices. For example, network link 420 may provide a connection through local network 422 to a host computer 424 or to data equipment operated by an Internet Service Provider (ISP) 426. ISP 426 in turn provides data communication services through the world wide packet data communication network now commonly referred to as the “Internet” 428. Local network 422 and Internet 428 both use electrical, electromagnetic or optical signals that carry digital data streams. The signals through the various networks and the signals on network link 420 and through communication interface 418, which carry the digital data to and from computer system 400, are example forms of transmission media.
Computer system 400 can send messages and receive data, including program code, through the network(s), network link 420 and communication interface 418. In the Internet example, a server 430 might transmit a requested code for an application program through Internet 428, ISP 426, local network 422 and communication interface 418.
The received code may be executed by processor 404 as it is received, and/or stored in storage device 410, or other non-volatile storage for later execution.
In the foregoing specification, embodiments of the invention have been described with reference to numerous specific details that may vary from implementation to implementation. The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. The sole and exclusive indicator of the scope of the invention, and what is intended by the applicants to be the scope of the invention, is the literal and equivalent scope of the set of claims that issue from this application, in the specific form in which such claims issue, including any subsequent correction.
This application claims the benefit of Provisional Application 62/245,869, filed Oct. 23, 2015, the entire contents of which is hereby incorporated by reference as if fully set forth herein, under 35 U.S.C. § 119(e).
Number | Name | Date | Kind |
---|---|---|---|
5359724 | Earle | Oct 1994 | A |
5367677 | Stanfill | Nov 1994 | A |
5546571 | Shan | Aug 1996 | A |
5822750 | Jou | Oct 1998 | A |
5848408 | Jackobsson | Dec 1998 | A |
5905985 | Malloy | May 1999 | A |
5915249 | Spencer | Jun 1999 | A |
5943666 | Kleewein | Aug 1999 | A |
5960428 | Lindsay | Sep 1999 | A |
6298342 | Graefe | Oct 2001 | B1 |
6317750 | Tortolani et al. | Nov 2001 | B1 |
6341281 | MacNicol | Jan 2002 | B1 |
6345267 | Lohman | Feb 2002 | B1 |
6353828 | Ganesh | Mar 2002 | B1 |
6397195 | Pinard et al. | May 2002 | B1 |
6397204 | Liu | May 2002 | B1 |
6405208 | Raghavan et al. | Jun 2002 | B1 |
6385604 | Bakalash et al. | Jul 2002 | B1 |
6446063 | Chen | Sep 2002 | B1 |
6460045 | Aboulnaga et al. | Oct 2002 | B1 |
6484179 | Roccaforte | Nov 2002 | B1 |
6529896 | Leung et al. | Mar 2003 | B1 |
6618729 | Bhashyam et al. | Sep 2003 | B1 |
6711563 | Koskas | Mar 2004 | B1 |
6775682 | Ballamkonda | Aug 2004 | B1 |
6959304 | Teig et al. | Oct 2005 | B1 |
6965891 | Jakobsson | Nov 2005 | B1 |
7028046 | Anjur et al. | Apr 2006 | B2 |
7103590 | Murthy | Sep 2006 | B1 |
7146370 | Klindt | Dec 2006 | B1 |
7174327 | Chau | Feb 2007 | B2 |
7324991 | Anjur | Jan 2008 | B1 |
7337163 | Srinivasan | Feb 2008 | B1 |
7366730 | Greenfield et al. | Apr 2008 | B2 |
7392248 | Bakalash | Jun 2008 | B2 |
7467127 | Baccash et al. | Dec 2008 | B1 |
7617312 | Tummalapalli | Nov 2009 | B2 |
7725425 | Smartt | May 2010 | B2 |
7734652 | Tamayo | Jun 2010 | B2 |
7769733 | Chen et al. | Aug 2010 | B2 |
7774303 | Shoup | Aug 2010 | B2 |
7797320 | Thomsen | Sep 2010 | B2 |
8001112 | Dombroski et al. | Aug 2011 | B2 |
8041670 | Bakalash | Oct 2011 | B2 |
8176265 | Coon | May 2012 | B2 |
8200612 | Soylemez | Jun 2012 | B2 |
8209208 | Kearney et al. | Jun 2012 | B2 |
8311975 | Gonsalves | Nov 2012 | B1 |
8396325 | Kwatra | Mar 2013 | B1 |
8554761 | Ahmed | Oct 2013 | B1 |
8660985 | Wang | Feb 2014 | B2 |
8788453 | Bakalash | Jul 2014 | B2 |
8799209 | Bakalash | Aug 2014 | B2 |
9092484 | Abraham | Jul 2015 | B1 |
9177027 | Kitsuregawa | Nov 2015 | B2 |
9183254 | Cole | Nov 2015 | B1 |
9324036 | Iyer | Apr 2016 | B1 |
9971808 | Kamath | May 2018 | B2 |
10091061 | Peterson | Oct 2018 | B1 |
20020095397 | Koskas | Jul 2002 | A1 |
20020095421 | Koskas | Jul 2002 | A1 |
20030208484 | Chang | Nov 2003 | A1 |
20040153435 | Gudbjartsson et al. | Aug 2004 | A1 |
20040225639 | Jakobsson | Nov 2004 | A1 |
20050033741 | Dombroski et al. | Feb 2005 | A1 |
20050131880 | Yoaz | Jun 2005 | A1 |
20060026115 | Ahmed | Feb 2006 | A1 |
20060080285 | Chowdhuri | Apr 2006 | A1 |
20060101001 | Lindsay | May 2006 | A1 |
20060184519 | Smartt | Aug 2006 | A1 |
20060200772 | Dhanapal | Sep 2006 | A1 |
20060235818 | Muras | Oct 2006 | A1 |
20060235823 | Chong | Oct 2006 | A1 |
20070027860 | Bestgen | Feb 2007 | A1 |
20070083489 | Lawande | Apr 2007 | A1 |
20070233648 | Zuzarte | Oct 2007 | A1 |
20070239673 | Barsness | Oct 2007 | A1 |
20070239691 | Ordonez | Oct 2007 | A1 |
20070250473 | Larson | Oct 2007 | A1 |
20070283356 | Du | Dec 2007 | A1 |
20080059415 | Bakalash | Mar 2008 | A1 |
20080162409 | Meijer | Jul 2008 | A1 |
20080172354 | Zuarte | Jul 2008 | A1 |
20080215544 | Galindo-Legaria | Sep 2008 | A1 |
20080306903 | Larson | Dec 2008 | A1 |
20090112793 | Ahemd | Apr 2009 | A1 |
20090182720 | Cain et al. | Jul 2009 | A1 |
20090265335 | Hoffman | Oct 2009 | A1 |
20090281985 | Aggarwal | Nov 2009 | A1 |
20100088325 | Goldstein | Apr 2010 | A1 |
20100191716 | Chen | Jul 2010 | A1 |
20100211577 | Shimizu | Aug 2010 | A1 |
20100299337 | Aurin | Nov 2010 | A1 |
20100299367 | Chakrabarti et al. | Nov 2010 | A1 |
20110010139 | Fuhrmann | Jan 2011 | A1 |
20110040745 | Zaydman | Feb 2011 | A1 |
20110047364 | Koju | Feb 2011 | A1 |
20110055246 | Le Biannic et al. | Mar 2011 | A1 |
20110137917 | Boland et al. | Jun 2011 | A1 |
20110145244 | Kim et al. | Jun 2011 | A1 |
20110173164 | Bendel | Jul 2011 | A1 |
20110196857 | Chen | Aug 2011 | A1 |
20110252033 | Narang | Oct 2011 | A1 |
20110282864 | Collins | Nov 2011 | A1 |
20120036146 | Annapragada | Feb 2012 | A1 |
20120296883 | Ganesh | Nov 2012 | A1 |
20120296942 | Arora | Nov 2012 | A1 |
20130006965 | Barbas | Jan 2013 | A1 |
20130060547 | Beran et al. | Mar 2013 | A1 |
20130073538 | Beerbower | Mar 2013 | A1 |
20130117255 | Liu | May 2013 | A1 |
20130173528 | Betawadkar | Jul 2013 | A1 |
20130198165 | Cheng | Aug 2013 | A1 |
20130262443 | Leida | Oct 2013 | A1 |
20130275364 | Wang | Oct 2013 | A1 |
20130275365 | Wang | Oct 2013 | A1 |
20130275367 | Shuma | Oct 2013 | A1 |
20140052711 | Bamba et al. | Feb 2014 | A1 |
20140095526 | Harada | Apr 2014 | A1 |
20140095534 | Aingaran | Apr 2014 | A1 |
20140099502 | Ziauddin | Apr 2014 | A1 |
20140101201 | Yan | Apr 2014 | A1 |
20140149480 | Catanzaro | May 2014 | A1 |
20140181072 | Wong | Jun 2014 | A1 |
20140181144 | Kashiyama | Jun 2014 | A1 |
20140214796 | Barber | Jul 2014 | A1 |
20140280020 | Singamshetty | Sep 2014 | A1 |
20150019674 | Le Van Gong | Jan 2015 | A1 |
20150088795 | Golovashkin et al. | Mar 2015 | A1 |
20150088856 | Hunter et al. | Mar 2015 | A1 |
20150088885 | Hopeman, IV et al. | Mar 2015 | A1 |
20150088919 | Hunter et al. | Mar 2015 | A1 |
20150261820 | Cheng | Sep 2015 | A1 |
20150278309 | Harada | Oct 2015 | A1 |
20150379077 | Grosse | Dec 2015 | A1 |
20160034521 | Lumby | Feb 2016 | A1 |
20160179889 | Chiang | Jun 2016 | A1 |
20160232206 | Hayamizu | Aug 2016 | A1 |
20160378751 | Kamath | Dec 2016 | A1 |
20160378754 | Kamath | Dec 2016 | A1 |
20160378796 | Hopcroft | Dec 2016 | A1 |
20170116266 | Lahorani et al. | Apr 2017 | A1 |
Entry |
---|
Louiqa Raschid et al., “A Parallel Processing Strategy for Evaluating Recursive Queries”, dated Aug. 1986, 8 pages. |
Ashdown et al., “Oracle Database SQL Tuning Guide 12c Release 1(12.1)”, dated May 2013, 566 pages. |
U.S. Appl. No. 14/033,251, filed Sep. 20, 2013, Final Office Action, dated Dec. 21, 2015. |
Hopeman, U.S. Appl. No. 14/033,251, filed Sep. 20, 2013, Notice of Allowance, dated Apr. 12, 2017. |
Hunter, U.S. Appl. No. 14/033,358, filed Sep. 20, 2013, Final Office Action, dated Sep. 21, 2017. |
Hunter, U.S. Appl. No. 14/033,358, filed Sep. 20, 2013, Interview Summary, dated May 1, 2017. |
Hunter, U.S. Appl. No. 14/033,358, filed Sep. 20, 2013, Interview Summary, dated Dec. 21, 2016. |
Hunter, U.S. Appl. No. 14/033,358, filed Sep. 20, 2013, Office Action, dated Mar. 9, 2017. |
Hunter, U.S. Appl. No. 14/033,358, filed Sep. 20, 2017, Interview Summary, dated Dec. 11, 2017. |
U.S. Appl. No. 14/033,251, filed Jan. 22, 2016, Interview Summary, dated Jan. 22, 2016. |
Hopeman IV, U.S. Appl. No. 14/033,251, filed Sep. 20, 2013, Interview Summary, dated Dec. 27, 2016. |
U.S. Appl. No. 14/033,251, filed Sep. 20, 2013, Final Office Action, dated Nov. 1, 2016. |
U.S. Appl. No. 14/033,358, filed on Sep. 20, 2013, Office Action, dated Apr. 6, 2016. |
U.S. Appl. No. 14/033,251, filed Sep. 20, 2013, Interview Summary, dated Aug. 16, 2016. |
U.S. Appl. No. 14/033,251, filed Sep. 20, 2013, Office Action, dated May 27, 2016. |
U.S. Appl. No. 14/033,358, filed Sep. 20, 2013, Advisory Action, dated Jan. 19, 2017. |
U.S. Appl. No. 14/033,358, filed Sep. 20, 2013, Final Office Action, dated Oct. 5, 2016. |
U.S. Appl. No. 14/033,358, filed Sep. 20, 2013, Final Office Action, dated Nov. 10, 2015. |
U.S. Appl. No. 14/033,358, filed Sep. 20, 2013, Office Action, dated Apr. 6, 2016. |
MSDN Library, “Dimension Set Entires”, NAV 2013 Documentation, dated Nov. 21, 2012, Retrieved on Sep. 13, 2017, 22 pages. |
Ziauddin, U.S. Appl. No. 15/268,528, filed Sep. 16, 2016, Interiview Summary, dated May 16, 2019. |
Ziauddin, U.S. Appl. No. 15/268,528, filed Sep. 16, 2016, Advisory Action, dated May 21, 2019. |
Lahorani, U.S. Appl. No. 15/268,519, filed Sep. 16, 2016, Notice of Allowance, dated May 23, 2019. |
Ziauddin, U.S. Appl. No. 15/268,528, filed Sep. 16, 2016, Notice of Allowance, dated Jan. 29, 2020. |
Ziauddin, U.S. Appl. No. 15/268,335, filed Sep. 16, 2016, Notice of Allowance, dated Jan. 24, 2020. |
Number | Date | Country | |
---|---|---|---|
20170116272 A1 | Apr 2017 | US |
Number | Date | Country | |
---|---|---|---|
62245869 | Oct 2015 | US |