Abstract: A data normalization system is described herein that represents multiple data types that are common within database systems in a normalized form that can be processed uniformly to achieve faster processing of data on superscalar CPU architectures. The data normalization system includes changes to internal data representations of a database system as well as functional processing changes that leverage normalized internal data representations for a high density of independently executable CPU instructions. Because most data in a database is small, a majority of data can be represented by the normalized format. Thus, the data normalization system allows for fast superscalar processing in a database system in a variety of common cases, while maintaining compatibility with existing data sets.

Abstract: Architecture that provides for greater interoperability between column stores and row stores by leveraging the advantages both have to offer. The architecture operates automatically (e.g., dynamically) to move between row oriented processing mode and batch processing mode, and the combination thereof, when it is more beneficial to run in one mode relative to the other mode, or both modes. The auto-switching of data processing between batch and row oriented mode occurs during the execution of a single query. The architecture can automatically modify an operator in the query tree and/or remove an operator if desired at runtime for more efficient processing. This approach also accounts for memory constraints for either of row or column processing.

Abstract: Systems and methods that eliminate non-qualifying data for queries against data warehouses and improve execution time, via a dynamic filter component(s). In general, such dynamic filter components are derived from data during processing of the query and without being explicitly defined by the users within a query forwarded to the data warehouse. Moreover, an evaluation component can monitor efficiency of filter components (e.g., number of rows that can be eliminated), and dynamically change and/or update the evaluation order of such filters.

Abstract: A database can have multiple requests applied at one time. Each of these requests requires a specific amount of server resources. There can be a differentiation of user-submitted workloads between each other. These workloads are a set of queries submitted by different users. Each query can have specific resource limits. In addition, each set can have specific resource limits.

Abstract: A data normalization system is described herein that represents multiple data types that are common within database systems in a normalized form that can be processed uniformly to achieve faster processing of data on superscalar CPU architectures. The data normalization system includes changes to internal data representations of a database system as well as functional processing changes that leverage normalized internal data representations for a high density of independently executable CPU instructions. Because most data in a database is small, a majority of data can be represented by the normalized format. Thus, the data normalization system allows for fast superscalar processing in a database system in a variety of common cases, while maintaining compatibility with existing data sets.

Abstract: Architecture that includes an index creation algorithm that utilizes available resources and dynamically adjusts to successfully scale with increased resources and be able to do so for any data distribution. The resources can be processing resources, memory, and/or input/output, for example. A finer level of granularity, called a segment, is utilized to process tuples in a partition while creating an index. The segment also aligns with compression techniques for the index. By choosing an appropriate size for a segment and using load balancing the overall time for index creation can be reduced. Each segment can then be processed by a single thread thereby limiting segment skew. Skew is further limited by breaking down the work done by a thread into parallelizable stages.

Abstract: Architecture that provides for greater interoperability between column stores and row stores by leveraging the advantages both have to offer. The architecture operates automatically (e.g., dynamically) to move between row oriented processing mode and batch processing mode, and the combination thereof, when it is more beneficial to run in one mode relative to the other mode, or both modes. The auto-switching of data processing between batch and row oriented mode occurs during the execution of a single query. The architecture can automatically modify an operator in the query tree and/or remove an operator if desired at runtime for more efficient processing. This approach also accounts for memory constraints for either of row or column processing.

Abstract: Various embodiments of the present invention are direct to the utilization of Blob Handles (BHs) which are an internal representation of a large value. BHs are immutable and stateless references to a large data object. The structure of a BH contains enough information to return an ILockBytes interface in order to provide access to the corresponding large data block, and a BH can also return information regarding its own lifetime description. A BH can be completely described using (a) a pointer to the beginning of BH data and (b) the byte-length of the BH.

Abstract: A system and method for updating collection-valued and other complex structured columns in a nested table using a nested extension of an UPDATE statement that is analogous to the syntax and semantics of the UPDATE statement that is used to modify scalar-valued columns of the table (called the outer UPDATE). Using the same syntactic and semantic constructs as the table at the outer level allows an existing implementation that processes modifications to relational tables to reuse its implementation techniques for processing outer updates to modify collection-valued columns as well. The UPDATE extensions enable the specification of updates to nested collections embedded at arbitrary levels of depth in the object model. The new syntax is embedded inside the outer UPDATE statement in a way that parallels the structure of the data itself and thus maps more directly to the user's conceptual model of the data.

Abstract: Systems and methods that eliminate non-qualifying data for queries against data warehouses and improve execution time, via a dynamic filter component(s). In general, such dynamic filter components are derived from data during processing of the query and without being explicitly defined by the users within a query forwarded to the data warehouse. Moreover, an evaluation component can monitor efficiency of filter components (e.g., number of rows that can be eliminated), and dynamically change and/or update the evaluation order of such filters.

Abstract: A database can have multiple requests applied at one time. Each of these requests requires a specific amount of server resources. There can be a differentiation of user-submitted workloads between each other. These workloads are a set of queries submitted by different users. Each query can have specific resource limits. In addition, each set can have specific resource limits.

Abstract: Various embodiments of the present invention are direct to the utilization of Blob Handles (BHs) which are an internal representation of a large value. BHs are immutable and stateless references to a large data object. The structure of a BH contains enough information to return an ILockBytes interface in order to provide access to the corresponding large data block, and a BH can also return information regarding its own lifetime description. A BH can be completely described using (a) a pointer to the beginning of BH data and (b) the byte-length of the BH.

Abstract: A technique for updating collection-valued and other complex structured columns in a nested table using a nested extension of an UPDATE statement that uses syntax and semantics to modify collection-valued columns in a way that is analogous to the syntax and semantics of the UPDATE statement that is used to modify scalar-valued columns of the table (called the outer UPDATE). Using the same syntactic and semantic constructs as the table at the outer level allows an existing implementation that processes modifications to relational tables to reuse its implementation techniques for processing outer updates to modify collection-valued columns as well. The UPDATE extensions enable the specification of updates to nested collections embedded at arbitrary levels of depth in the object model. The new syntax is embedded inside the outer UPDATE statement in a way that parallels the structure of the data itself and thus maps more directly to the user's conceptual model of the data.