Abstract: A service identifying and processing method using a wireless terminal message according to an exemplary embodiment of the present invention includes (a) receiving a wireless terminal message by a first entity which is a mobile device; and (b) expressing, by a first agent which is an information processing application program installed on the first entity, entity information of second entity based on the wireless terminal message and service confirmation information related to service provided by the second entity, through an application screen by the first agent.

Abstract: Provided is a system and method for reconstructing and visualizing transformation steps that are performed to an optimized database query. In one example, the method may include receiving a database query including an initial set of execution steps, generating a plurality of alternative sets of execution steps for the database query based on transformations to the initial set of execution steps, selecting an alternative set of execution steps from among the plurality of alternative sets of execution steps based on a performance of the alternative set of execution steps, identifying transformations that are used to transform the initial set of execution steps into the selected alternative set of execution steps, and displaying information about the identified transformations via a user interface.

Abstract: Methods, systems, and computer-readable storage media for calculating, for each operator in a set of operators, a set of costs, each cost associated with a data format and including a first segment indicating a cost of an operator to convert an incoming data format to an access format and a second segment indicating a cost based on a set of costs of one or more ancestors of the operator, a conversion cost, and a materialization cost, indicating, along the path within the query plan, a location representing execution of a conversion from a first data format to a second data format, the location being selected based on the sets of costs, and providing the query plan with the location for execution to generate a query result, wherein during execution of the query plan, conversion of data from the first data format to the second data format occurs at the location.

Abstract: Methods, systems, and computer-readable storage media for calculating, for each operator in a set of operators, a set of costs, each cost associated with a data format and including a first segment indicating a cost of an operator to convert an incoming data format to an access format and a second segment indicating a cost based on a set of costs of one or more ancestors of the operator, a conversion cost, and a materialization cost, indicating, along the path within the query plan, a location representing execution of a conversion from a first data format to a second data format, the location being selected based on the sets of costs, and providing the query plan with the location for execution to generate a query result, wherein during execution of the query plan, conversion of data from the first data format to the second data format occurs at the location.

Abstract: Methods and apparatus, including computer program products, are provided for a case join. In one aspect, there is provided method, which may include receiving a query for a predefined view that is configured to inhibit modification; detecting whether the predefined view includes a database table extended to include an additional column; and generating, in response to the query, a view based on a case join, when the predefined view includes the database table extended to include the additional column. Related apparatus, systems, methods, and articles are also described.

Abstract: Provided is a system and method for reconstructing and visualizing transformation steps that are performed to an optimized database query. In one example, the method may include receiving a database query including an initial set of execution steps, generating a plurality of alternative sets of execution steps for the database query based on transformations to the initial set of execution steps, selecting an alternative set of execution steps from among the plurality of alternative sets of execution steps based on a performance of the alternative set of execution steps, identifying transformations that are used to transform the initial set of execution steps into the selected alternative set of execution steps, and displaying information about the identified transformations via a user interface.

Abstract: In a general aspect, a computer-implemented method for executing a query on a table of a database, where the table has multiple partitions, can include receiving a query requesting a view on the table. The view on the table can be based on data included in a partition of the multiple partitions of the table. The method can also include determining a cached result to the query is not available in the database and generating a result to the query from, at least, the data of the partition of the multiple partitions. After the generating, the method can include building a cache including the result to the query, associating a transaction identifier for the query with the result to the query result in the cache; and returning the result to the query.

Abstract: Disclosed herein are system, method, and computer program product embodiments for utilizing join cardinality to improve the performance of query processing. An embodiment operates by a database engine receiving a query including a join operation on a first and a second table using a join predicate, and a tag for the join operation indicating a cardinality relationship between the first and the second table when satisfying the join predicate. Then, the database engine generates a query processing plan for performing the query. For the join operation, the database engine selects one of the first or the second tables to remove from the join operation based on a type of the join operation and the tag. Based on the selecting, the database engine may remove may the join operation and the selected table from the query processing plan.

Abstract: Embodiments relate to view caching techniques that cache for a limited time, some of the (intermediate) results of a previous query execution, in order to avoid expensive re-computation of query results. Particular embodiments may utilize a cache manager to determine whether information relevant to a subsequent user request can be satisfied by an existing cache instance or view, or whether creation of an additional cache instance is appropriate. At design time, cache defining columns of a view are defined, with user input parameters automatically being cache defining. Cache instances are created for each tuple of literals for the cache defining columns, and for each explicit or implicit group by clause. Certain embodiments may feature enhanced reuse between cache instances, in order to limit memory footprint. Over time a cache instances may be evicted from memory based upon implementation of a policy such as a Least Recently Used (LRU) strategy.

Abstract: Disclosed herein are system, method, and computer program product embodiments for utilizing join cardinality to improve the performance of query processing. An embodiment operates by a database engine receiving a query including a join operation on a first and a second table using a join predicate, and a tag for the join operation indicating a cardinality relationship between the first and the second table when satisfying the join predicate. Then, the database engine generates a query processing plan for performing the query. For the join operation, the database engine selects one of the first or the second tables to remove from the join operation based on a type of the join operation and the tag. Based on the selecting, the database engine may remove may the join operation and the selected table from the query processing plan.

Abstract: Methods and apparatus, including computer program products, are provided for a case join. In one aspect, there is provided method, which may include receiving a query for a predefined view that is configured to inhibit modification; detecting whether the predefined view includes a database table extended to include an additional column; and generating, in response to the query, a view based on a case join, when the predefined view includes the database table extended to include the additional column. Related apparatus, systems, methods, and articles are also described.

Abstract: Embodiments relate to re-writing database query plans, and visualizing such re-written query plans. A query re-write framework includes a query normalization engine in communication with a rule catalog comprising query re-write rules in the form of rule classes. The framework receives as input, a query plan graph to be re-written. Based upon the engine's application of re-write rules from the catalog, the framework produces a re-written query plan graph as output. An interface component of the framework may provide a visualization of the re-written query plan graph as part of a dashboard. A user may access the framework to enable/disable existing rules in the catalog, add new rules to the catalog, and/or control a sequence and a precedence in which rules are applied to re-write the query plan. A user may interact with the visualization of the re-written query plan for purposes of de-bugging, re-write optimization, and/or query development.

Abstract: In a general aspect, a computer-implemented method for executing a query on a table of a database, where the table has multiple partitions, can include receiving a query requesting a view on the table. The view on the table can be based on data included in a partition of the multiple partitions of the table. The method can also include determining a cached result to the query is not available in the database and generating a result to the query from, at least, the data of the partition of the multiple partitions. After the generating, the method can include building a cache including the result to the query, associating a transaction identifier for the query with the result to the query result in the cache; and returning the result to the query.

Abstract: Embodiments relate to re-writing database query plans, and visualizing such re-written query plans. A query re-write framework includes a query normalization engine in communication with a rule catalog comprising query re-write rules in the form of rule classes. The framework receives as input, a query plan graph to be re-written. Based upon the engine's application of re-write rules from the catalog, the framework produces a re-written query plan graph as output. An interface component of the framework may provide a visualization of the re-written query plan graph as part of a dashboard. A user may access the framework to enable/disable existing rules in the catalog, add new rules to the catalog, and/or control a sequence and a precedence in which rules are applied to re-write the query plan. A user may interact with the visualization of the re-written query plan for purposes of de-bugging, re-write optimization, and/or query development.

Abstract: Embodiments relate to re-writing database query plans, and visualizing such re-written query plans. A query re-write framework includes a query normalization engine in communication with a rule catalog comprising query re-write rules in the form of rule classes. The framework receives as input, a query plan graph to be re-written. Based upon the engine's application of re-write rules from the catalog, the framework produces a re-written query plan graph as output. An interface component of the framework may provide a visualization of the re-written query plan graph as part of a dashboard. A user may access the framework to enable/disable existing rules in the catalog, add new rules to the catalog, and/or control a sequence and a precedence in which rules are applied to re-write the query plan. A user may interact with the visualization of the re-written query plan for purposes of de-bugging, re-write optimization, and/or query development.

Abstract: Embodiments relate to re-writing database query plans, and visualizing such re-written query plans. A query re-write framework includes a query normalization engine in communication with a rule catalog comprising query re-write rules in the form of rule classes. The framework receives as input, a query plan graph to be re-written. Based upon the engine's application of re-write rules from the catalog, the framework produces a re-written query plan graph as output. An interface component of the framework may provide a visualization of the re-written query plan graph as part of a dashboard. A user may access the framework to enable/disable existing rules in the catalog, add new rules to the catalog, and/or control a sequence and a precedence in which rules are applied to re-write the query plan. A user may interact with the visualization of the re-written query plan for purposes of de-bugging, re-write optimization, and/or query development.

Abstract: Embodiments relate to view caching techniques that cache for a limited time, some of the (intermediate) results of a previous query execution, in order to avoid expensive re-computation of query results. Particular embodiments may utilize a cache manager to determine whether information relevant to a subsequent user request can be satisfied by an existing cache instance or view, or whether creation of an additional cache instance is appropriate. At design time, cache defining columns of a view are defined, with user input parameters automatically being cache defining. Cache instances are created for each tuple of literals for the cache defining columns, and for each explicit or implicit group by clause. Certain embodiments may feature enhanced reuse between cache instances, in order to limit memory footprint. Over time a cache instances may be evicted from memory based upon implementation of a policy such as a Least Recently Used (LRU) strategy.