Skip to content
Free planNo credit card requiredStart writing

Search 250 million research papers

Read the abstract, see who wrote it and who cites it, and get the citation in APA, MLA, Chicago or Harvard.

About 1,113 papers for “query optimizer”

Query Optimizer Basics

Andrew Carruthers · Apress eBooks · 2022

Performance tuning is often regarded as a “black” art, available to those with experience gained over many years of hands-on work. This section offers insights into how Snowflake works “under the hood” and provides tools to better understand behavior and identify options to improve performance.

Cited by 0

The Query Optimizer

Andrew Carruthers · Apress eBooks · 2024

Query optimizers reduce the cost of queries while retaining the original intended functionality. Furthermore, query optimization seeks to reduce the volume of data accessed, further reducing costs.

Cited by 0

Web query optimizer

Vladimir Zadorozhny, Laura F. Bright, Louiqa Raschid et al. · 2002

We demonstrate a Web Query Optimizer (WQO) within an architecture of mediators and wrappers, for WebSources of limited capability in a wide area environment. The WQO has several innovative features, including a CBR (capability based rewriting) tool, an enhanced randomized relational optimizer extended to a Web environment, and a WebWrapper cost model that can provide relevant metrics for accessing WebSources. The prototype has been tested against a number of WebSources.

Cited by 4

CC-Optimizer: A Cache Conscious Query Optimizer

Yoshishige Tsuji, Hideyuki Kawashima · 2007

The difference between CPU access costs and memory access costs incurs performance degradations on RDBMS. One of the reason why instruction cache misses occur is the size of footprint on RDBMS operations does not fit into a L1 instruction cache. To solve this problem Zhou proposed the buffering operator which changes the order of operation executions. Although the buffering operator is effective, it cannot be applied for RDBMS in the real business. It is because Zhou does not show an algorithm for optimizer to select the buffering operator. Thus we realized the CC-Optimizer which includes an algorithm to appropriately select the buffering operator. Our contributions are the design of new algorithm on an optimizer and its implementation to RDBMS. For experimental RDBMS, we used PostgreSQL as Zhou did, and our machine environment was Linux Kernel 2.6.15,CPU Intel Pentium 4(2.40GHz). The result of preliminary experiments showed that CC-Optimizer was effective. The performance improvement measured by using OSDL DBT-3, was 32.3% in the greatest result, and 6.08% in all queries.

Cited by 0

Configuring the Query Optimizer

Apress eBooks · 2008

The query optimizer is directly responsible for the performance of SQL statements. For this reason, it makes sense to take some time to configure it correctly. In fact, without an optimal configuration, the query optimizer may generate inefficient execution plans that lead to poor performance.KeywordsInitialization ParameterObject StatisticWork AreaExecution PlanQuery OptimizerThese keywords were added by machine and not by the authors. This process is experimental and the keywords may be updated as the learning algorithm improves.

Cited by 0

ARQ Static Query Optimizer

Markus Stocker, Andy Seaborne, Markus Stocker et al. · 2007

semantic web, SPARQL, query optimization In this paper we describe the architecture of ARQo, a first approach for SPARQL static query optimization in ARQ. Specifically, we focus on static optimization of BasicGraphPattern (BGP) for in-memory models. Static query optimization is intended as a query rewriting process where the set of triple patterns defined for a BGP are rewritten according to a specific order. We propose a rewriting process according to the estimated execution cost of joined triple patterns in increasing order. Specifically, the estimated execution cost is a function of multiple parameters such as the estimated selectivity of joined triple patterns, the availability of indexes or pre-calculated result sets.

Cited by 0

SQL Query Optimizer-based Query Progress Indicator

Urmila Mane · 2013

Nowadays, widely used Business Intelligence(BI) and Data Warehousing(DW) technologies are mostly based on long- running and complex queries. So for this purpose it is important for users to have information about progress of query execution. Recently interest in the development of percent-done progress indicators has been increased. In this paper, we propose a method that constructs model of a percent-done progress indicators based on optimizer-based approach. Percent-done progress indicators basically used as a technique that graphically shows query execution time that means total and remaining or degree of completion. Also the proposed technique is based on postgerSQL database engine. PostgreSQL is a powerful, open source object-relational database system. Currently Postgres doesn't have SQL query progress indicator for long-running queries. With the help of user-system interaction (interface) the progress indicator show the progress of SQL queries through various phases like parsing, analyzing, rewrite, execution. The graphical user interface show all the queries running on system and their estimated time completion. The execution phase of query is critical phase and also the cost of query varies depending disk read time, type of join used, distribution or broadcast of table, order in which tables are joined, statistics information available.

Cited by 0

FORTE: Online DataFrame Query Optimizer

Yoonho Choi, Kyoungtae Lee, Minji Kim et al. · 2026

DataFrame libraries are widely adopted in data science for their flexible, Pythonic interfaces, but their fragmented APIs and unstructured query patterns limit systematic optimization. Existing work has explored parallel execution or SQL-style logical rewrites, yet these approaches fall short in capturing DataFrame-specific semantics and Python control-flow context. We present FORTE, the first online, source-to-source query optimizer that unifies multiple DataFrame libraries under a shared intermediate representation (DFL). DFL makes DataFrame semantics explicit, enabling composable and portable rewriting rules such as user-defined function (UDF) lifting/lowering, loop lifting, and API tuning, alongside classical rewrites (e.g., predicate pushdown). FORTE employs a lightweight, learned cost model and greedy search to apply these rewrites with negligible overhead, while supporting both intra-library optimization and cross-library transpilation. Our evaluation on TPC-H workloads and real-world Kaggle/GitHub workloads shows that FORTE consistently delivers substantial speedups—up to 52.53× (3.7× on average) across Pandas, Modin, Polars, and Pandas-on-Spark—demonstrating that online, IR-guided rewriting can significantly outperform existing DataFrame engines and rewriters, while enabling cross-library retargetability.

Cited by 0

AlphaQO: Robust Learned Query Optimizer

X. D. Yu, Chengliang Chai, Xinning Zhang et al. · International Journal of Software and Informatics · 2022

Recently, learned query optimizers typically driven by deep learning models have attracted wide attention as they can offer similar or even better performance than state-of-the-art commercial optimizers. A successful learning optimizer often relies on enough high-quality load queries as training data, and poor-quality training will lead to the query failure of learned query optimizers. In this paper, we propose a novel training framework AlphaQO for robust learned query optimizers based on Reinforcement Learning (RL), and the robustness of the optimizers can be improved by finding the bad queries in advance. AlphaQO is a loop system consisting of two main components, namely the query generator and the learned optimizer. A query generator aims at generating ``difficult'' queries (i.e., queries that the learned optimizer provides poor estimates). The learned optimizer will be trained using these generated queries, as well as providing feedback (in terms of numerical rewards) to the query generator for updates. If the generated queries are good, the query generator will get a high reward; otherwise, the query generator will get a low reward. The above process is performed iteratively, with the main goal that within a small budget, the learned optimizer can be trained and generalized well to a wide range of unseen queries. Extensive experiments show that AlphaQO can generate a relatively small number of queries and train a learned optimizer to outperform commercial optimizers. Moreover, learned optimizers require much fewer queries from AlphaQO than randomly generated queries for the quality training of the learned optimizer.

Cited by 1Open access

HadoopToSQL: a MapReduce Query Optimizer

Iu, Christopher Ming-Yee, Zwaenepoel, Willy · Infoscience (Ecole Polytechnique Fédérale de Lausanne) · 2010

Map Reduce is a cost-effective way to achieve scalable performance for many log-processing workloads. These workloads typically process their entire dataset. Map Reduce can be inefficient, however, when handling business-oriented workloads, especially when these workloads access only a subset of the data.

Cited by 2Open access

Presto's History-Based Query Optimizer

Pranjal Shankhdhar, Feilong Liu, Jay Narale et al. · Proceedings of the VLDB Endowment · 2024

An important feature of modern query optimizers is the ability to produce a query plan that is optimal for the underlying data set. This requires the ability to estimate cardinalities and computational costs of intermediate query plan nodes, which is highly dependent on both the query shape and the underlying data distribution. Traditional methods include collecting statistics on base tables and implementing cardinality and computational cost derivation inside the optimizer, which is error-prone for complex query shapes. This paper presents Presto's novel history-based optimization framework (HBO), which collects execution histories and uses them to optimize similar queries in the future. The framework produces accurate estimates for complex query shapes in a lightweight, automated manner, and adapts automatically to changes in underlying data distributions. We present the design and implementation of the HBO framework and provide details on its use in various optimization rules, as well as details on implementing the statistics store on top of a Redis key-value store. We also present the results of running HBO in production in two large data infrastructure organizations (Meta and Uber).

Cited by 1

A Region Based Query Optimizer through Cascades Optimizer Framework

Fatma Ozcan, Sena Nural, Pinar Koksal et al. · 1995

The Cascades Query Optimizer Framework is a tool to help the database implementor (DBI) in constructing a query optimizer for a DBMS. It is data model independent and allows to code a query optimizer by providing the implementations of the subclasses of prede ned interface classes. When the implementations of the required classes are provided properly, the generated optimizer produces the optimum execution plans for the queries. Although providing the complete set of rules and thus nding the optimum execution plans are bene cial for most of the queries, the query optimization time increases unacceptably for certain types of queries, e.g., for star queries. Hence it is important to be able to limit the number of alternative plans considered by the optimizer for speci c types of queries by using the proper heuristics for each type. This leads to the concept of region based query optimization, where di erent types of queries are optimized by using di erent search strategies in each region. This paper describes our experiences in developing a region based query optimizer through Cascades. Cascades' guidance structures provide the facilities required for the design and implementation of a region based optimizer. The performance comparisons between a region based query optimizer and an exhaustive (which uses the complete rule set without heuristic guidance) query optimizer, both generated through Cascades, indicate that the region based optimizer has a superior performance. In the performance analysis, both the sum of optimization and execution times, namely the response time, and the quality of the plans generated are investigated. 1

Cited by 0

The Corporate Mass Data Query Optimizer

Yong Ding · Computer Science and Application · 2013

在一个应用系统中,对数据查询及处理速度已成为衡量该系统成败的标准,所以在对大型数据库查询时,应注意数据查询的工作效率,以免造成系统资源严重浪费。本文根据以语法为基础的查询优化器的工作原理,合理建立索引,书写规范良好的SQL语句,使用合适的表达式或关键字,充分利用索引,避免全表扫描,提高查询效率。 In an application system, data query and processing speed has become a standard to measure the success or failure of the system. Thus, in large database queries, you should pay attention to the efficiency of the data query, so as not to cause a serious waste of system resources. Based on the grammar-based query optimizer works, this paper reasonably establishes indexing, writes good specifications SQL statement, uses appropriate expressions or keywords, makes full use of the index, avoids full table scan and improves query efficiency.

Cited by 0

Reduction of Query Optimizer Plan Diagrams

Harish D. Pooja, N. Darera, Jayant R. Haritsa · 2014

A “plan diagram ” is a pictorial enumeration of the execution plan choices of a database query optimizer over the relational selectivity space. We have shown recently that, for industrial-strength database engines, these diagrams are often remarkably complex and dense, with a large number of plans covering the space. However, they can often be reduced to much simpler pictures, featuring significantly fewer plans, without materially affecting the query processing quality. Plan reduc-tion has useful implications for the design and usage of query optimizers, including quantifying redundancy in the plan search space, enhancing useability of parametric query optimization, iden-tifying error-resistant and least-expected-cost plans, and minimizing the overheads of multi-plan approaches. We investigate here the plan reduction issue from theoretical, statistical and empirical perspec-tives. Our analysis shows that optimal plan reduction, w.r.t. minimizing the number of plans, is an NP-hard problem in general, and remains so even for a storage-constrained variant. We then present a greedy reduction algorithm with tight and optimal performance guarantees, whose complexity scales linearly with the number of plans in the diagram for a given resolution. Next, we devise fast estimators for locating the best tradeoff between the reduction in plan cardinality and the impact on query processing quality. Finally, extensive experimentation with a suite of multi-dimensional TPC-H and TPC-DS based query templates on industrial-strength optimizers demonstrates that complex plan diagrams easily reduce to “anorexic ” (small absolute number of plans) levels incurring only marginal increases in the estimated query processing costs. 1

Cited by 0

The Picasso database query optimizer visualizer

Jayant R. Haritsa · Proceedings of the VLDB Endowment · 2010

Modern database systems employ a query optimizer module to automatically identify the most efficient strategies for executing the declarative SQL queries submitted by users. The efficiency of these strategies, called "plans", is measured in terms of "costs" that are indicative of query response times. Optimization is a mandatory exercise since the difference between the costs of the best execution plan, and a random choice, could be in orders of magnitude. The role of query optimizers has become especially critical during this decade due to the high degree of processing complexity characterizing current data warehousing and mining applications, as exemplified by the TPC-H and TPC-DS decision support benchmarks [20, 21].

Cited by 38

Benchmarking the DBS3 parallel query optimizer

Mohamed Zaït, Daniela Florescu, Patrick Valduriez · IEEE Parallel & Distributed Technology Systems & Applications · 1996

The DBS3 optimizer demonstrates solutions to cost modeling problems posed by a rich execution model. The optimizer models various execution plan formats, including bushy and zigzag trees, and pipelining is an important aspect of the cost model.

Cited by 3