Predictive IndexingJoy Arulraj∗ Ran Xian† Lin Ma‡, Andrew Pavlo§

Carnegie Mellon UniversityEmail: ∗jarulraj@cs.cmu.edu, †rxian@cs.cmu.edu, ‡lin.ma@cs.cmu.edu, §pavlo@cs.cmu.edu

Abstract—There has been considerable research on automatedindex tuning in database management systems (DBMSs). Butthe majority of these solutions tune the index configurationby retrospectively making computationally expensive physicaldesign changes all at once. Such changes degrade the DBMS’sperformance during the process, and have reduced utility duringsubsequent query processing due to the delay between a workloadshift and the associated change. A better approach is to generatesmall changes that tune the physical design over time, forecastthe utility of these changes, and apply them ahead of time tomaximize their impact.

This paper presents predictive indexing that continuouslyimproves a database’s physical design using lightweight physicaldesign changes. It uses a machine learning model to forecastthe utility of these changes, and continuously refines the indexconfiguration of the database to handle evolving workloads. Weintroduce a lightweight hybrid scan operator with which a DBMScan make use of partially-built indexes for query processing.Our evaluation shows that predictive indexing improves thethroughput of a DBMS by 3.5–5.2× compared to other state-of-the-art indexing approaches. We demonstrate that predictiveindexing works seamlessly with other lightweight automatedphysical design tuning methods.

I. INTRODUCTION

The performance of modern data-driven applications isoften constrained by that of the underlying DBMS. Thephysical design of the database plays a dominant role indetermining the system’s performance. Thus, it is importantto tune it based on the application’s query workload. One keycomponent of the physical design problem is to determinea set of indexes that balances the trade-off of acceleratingquery execution and reducing index maintenance overhead.Database administrators (DBAs) address this problem usingindex advisors that are offered by most database vendors [1, 2].These tools recommend indexes to build based on the currentindex configuration of the database and the query workload.

Index advisors require a DBA to provide a representativeworkload collected over some period of time (e.g., severalweeks). But in modern hybrid transaction-analytical processing(HTAP) workloads, it is unlikely that an index is globallyuseful over the entire workload [3, 4]. DBAs must, therefore,continuously monitor and re-tune the index configuration toensure that indexes that are appropriate for the current queryworkload are available. Such an offline index tuning processinvolves performing large computationally expensive indexconfiguration changes. DBAs are required to carefully schedulethese index building operations during non-peak hours or offlinemaintenance breaks to minimize their impact on the application.With these offline approaches, the DBMS cannot react in timeto workload changes.

Several indexing approaches have been proposed to addressthe limitations of offline index advisors, such as onlineindexing [3, 5], adaptive indexing [6], self-managing index-ing [7], and holistic indexing [4]. Online indexing obviatesthe need for manually scheduling index configuration changesby automatically monitoring the workload and refining theindex configuration. It still, however, involves computationallyexpensive changes, such as immediately building an entireindex, which degrade the performance of the DBMS whilethey are being applied. Adaptive and self-managing indexingschemes instead advocate an incremental approach towardsindex tuning, wherein the index configuration of the DBMSis evolved using smaller steps. They build indexes partiallyand incrementally during query processing, and amortize theoverhead of constructing an ad-hoc index across several queries.The main limitation of these schemes is that they only refinethe indexes during query processing, and do not leverage idlesystem resources when the DBMS is not processing any queries.Holistic indexing overcomes this limitation by enabling theDBMS to use idle system resources for optimistically evolvingthe index configuration.

All of these indexing approaches examine the recent querywork- load in hindsight to determine the set of indexes thatmust be refined next. This retrospective approach towards indextuning increases the delay between a workload shift and theassociated physical design change, thereby reducing the utilityof the indexes. Another limitation is that these approaches canstill degrade the performance of the DBMS while applying theindex configuration changes. For example, even with holisticindexing, the index tuner might start populating a substantialpart of an index while processing a query to materialize all theindex entries matching the query’s predicate. This increases thequery’s latency. Such latency spikes may prevent the DBMSfrom honoring latency service-level agreements.

In this paper, we present predictive indexing that uses amachine learning (ML) model to predict the utility of indexes infuture, and adapts the index configuration of the database aheadof time to increase the utility of indexes. We propose a simplelightweight value-agnostic hybrid scan operator that allowsthe DBMS to use partially-built indexes without incurringlatency spikes. A summary of the differences between predictiveindexing and other state-of-the-art indexing approaches ispresented in Table I.

To evaluate our approach, we implemented the predictiveindex tuner and the hybrid scan operator in DBMS-X, anin-memory HTAP DBMS that is designed for autonomousoperation [9]. We examine the impact of predictive indexing

arX

iv:1

901.

0706

4v1

[cs

.DB

] 2

1 Ja

n 20

19

IndexingApproach

WorkloadType

IndexType

AlwaysOn

DecisionLogic

HybridScan

Offline [1, 8] Static Full × × ×Online [3, 5] Dynamic Full X Retrospective×Adaptive [6],

Self-managing [7]

Dynamic Partial × ImmediateValue-based

Holistic [4] Dynamic Partial X ImmediateValue-based

Predictive Dynamic Partial X Predictive Value-agnostic

TABLE I: Comparison of Automated Indexing Approaches –Qualitative differences among the different indexing schemes withrespect to the types of supported workloads and indexes built, theability to always evolve the index configuration, and the types ofdecision logic and hybrid scan employed.

on the DBMS’s performance and its ability to handle evolvingworkloads. Our results show that predictive indexing improvesDBMS-X’s throughput by 3.5–5.2× compared to other state-of-the-art indexing approaches. In summary, this paper makesthe following contributions:

• We present a predictive indexing approach that usesreinforcement learning to forecast the utility of the indexconfiguration and tunes it ahead of time. We proposea lightweight value-agnostic hybrid scan operator withwhich the DBMS can make use of partially-built indexes.• We implement an end-to-end index tuner that decides

both when and how to adapt the index configuration. Weintegrate different indexing approaches in the same DBMS,including (1) online [3, 5], (2) adaptive [6], (3) self-managing [7], (4) holistic [4], and (5) predictive. We alsodevelop a new open-source benchmarking suite to performa detailed comparison of these indexing approaches [9].

• We demonstrate that predictive indexing works seamlesslywith other automated physical design tuners, and is a stepforward towards DBMSs designed for autonomous oper-ation. By working in tandem, the predictive index tunerand the storage layout tuner solve two key componentsof the physical design problem.

The remainder of this paper is structured as follows. We firstdiscuss the benefits of predictive indexing, and then highlightthe performance impact of the hybrid scan operator on HTAPworkloads in Section II. Next, in Section III, we describethe design of the hybrid scan operator. We then present thepredictive ML model that forms the underlying decision logicof the tuner in Section IV, followed by our index tuningbenchmark in Section V. We then present our experimentalevaluation in Section VI. We conclude with a discussion ofrelated work in Section VII.

II. MOTIVATION

An important aspect of modern database applications isthat their query patterns evolve over time. These changesreflect the hourly, daily, or weekly processing cycles of

an organization. For instance, consider a stock exchangeapplication. During regular trading hours, it generates a write-intensive online transaction processing (OLTP) workload. Afterthe trading hours are over, it mostly executes read-intensiveonline analytical processing (OLAP) queries that examine thedata collected during the day. At the end of every week, it runsmore complicated analytics to generate reports and summaries.

Several indexing approaches have been proposed to allowthe DBMS to handle such dynamic workloads by automaticallyadapting the index configuration during different workloadphases [3–7]. These approaches have two main limitations.First, they can degrade the performance of the DBMS whileapplying a physical design change. For example, the tunermight start populating a substantial part of an ad-hoc indexwhile processing a query, thereby increasing the query’s latency.Second, the utility of the physical design change is dampeneddue to the delay between a workload shift and the associatedchange. We refer to this delay as the tuner’s reaction time.This reaction time is comprised of two components: (1) thedetection time is how long it takes to detect a workload shiftand pick a physical design change, and (2) the adaptationtime is how long it takes to apply the change and leverage itduring query processing. Longer reaction times decrease theutility of indexes that are dynamically built to accelerate queryprocessing.

Predictive indexing shrinks the tuner’s detection time byemploying a ML model to forecast the utility of the changes sothat they can be applied ahead of time. It incrementally buildsindexes using lightweight changes to prevent latency spikes.The DBMS employs a hybrid scan operator to leverage thesepartially-built indexes during query processing, and therebyshrinks the adaptation time.

Target Workloads: Predictive indexing accelerates produc-tion HTAP workloads containing both recurring and ad-hocqueries. As the workload evolves over time with recurringqueries being added and removed, the predictive index tunerlearns to forecast the utility of the index configuration, andadapts it ahead of time using lightweight changes. This shrinksthe DBMS’s reaction time on evolving HTAP workloads, andobviates the need for periodic manual tuning. We next discusshow predictive indexing differs from other state-of-the-artapproaches, and then highlight the performance impact ofhybrid scan on HTAP workloads in Section II-B.

A. Predictive Decision Logic

Every indexing approach is driven by a decision logic (DL)that determines the type of physical design changes made,and when these changes are applied. Online indexing schemesemploy a retrospective DL that examines the history of the lastk queries executed to determine the set of indexes that couldhave helped accelerate processing those queries [3, 10, 11].The main limitation of retrospective DL is that it increases thedetection time of the tuner as it needs to examine a longerwindow of queries. Longer reaction times of retrospective DLdecrease the utility of the changes.

30000

106

201

104 201

40000

105 40000

202

20000

203

202

10000

101

102

10000201

103

LOCATION SALARYEMP-IDSALARY INDEX

20000

30000

10000

40000

107 30000

202

109 203

108 30000

201

50000

INDEXSCAN

TABLESCAN

Page1

Page2

Page3

Fig. 1: Hybrid Scan – Value-agnostic hybrid scan over the EMPLOYEEtable and the partially-built ad-hoc index on its SALARY attribute.

In contrast, adaptive, self-managing, and holistic approachesadopt an immediate DL (k = 1) [4, 6, 7]. With immediate DL,the tuner only examines the most recent query while pickingan index for construction, and thus has a shorter detectiontime. But it cannot guard against noisy workloads with one-offqueries as it immediately starts building indexes to acceleratethem. With a retrospective DL, the tuner would not immediatelyconstruct these indexes as it examines a longer window ofqueries to estimate their utility before building them.

Predictive DL addresses the limitations of these two ap-proaches. It uses a statistical estimator that captures workloadtrend and seasonality to forecast the utility of indexes. Forexample, the predictive index tuner can detect that a workloadshift occurs every day at 8am, and then build a candidateindex ahead of time at 7am, so that the index is immediatelyavailable for query processing after the workload shift. Thus,this forecasting technique reduces the tuner’s detection time.Like retrospective DL, it examines a longer window of queriesbefore picking a physical design change. This increases itsdetection time when it encounters a one-off query for the firsttime, but once it captures the query’s trend, it detects it ahead-of-time. In this manner, predictive DL can both reduce thetuner’s detection time, and guard against noisy workloads withone-off queries. We next present how our hybrid scan operatorhelps shrink the tuner’s adaptation time.

B. Hybrid Scan

The DBMS can make use of ad-hoc indexes constructedby an index tuner in three ways. We illustrate the differencesbetween these approaches using an example. Consider theEMPLOYEE table shown in Figure 1; assume that it is not indexed.Suppose the application executes multiple analytical queriesthat compute the total salary of all employees whose salaryfalls within a range:

SELECT SUM(salary) FROM EMPLOYEEWHERE salary > t1 AND salary < t2

In this scenario, the tuner would observe that the predicatein these queries repeatedly accesses the salary attribute, andbuild an index to accelerate these queries. Among the threeapproaches for using this index, the first one is to start using

it only after it is fully populated. This is referred to as the fullscheme (FULL), and is employed by online indexing [12–14].The main limitation of this approach is that it increases theadaptation time, thus shrinking the utility of the index duringquery processing. A better way is to use the index even whenthe DBMS has not finished populating it.

Holistic, adaptive, and self-managing indexing approachesadopt such a value-based partial scheme (VBP) [4, 6, 7]. WithVBP, the tuner adds index entries based on the values presentin the predicate of the queries. For the EMPLOYEE table query,the tuner will add index entries for employees whose salary∈ (t1, t2). The DBMS can, then, efficiently handle subsequentqueries accessing the same sub-domain of the salary attributeusing the index. However, it can do so only after the sub-domain is completely indexed. Another limitation of VBP is thatit can still degrade the DBMS’s performance while building theindex. When the number of employees whose salary ∈ (t1, t2)is large, the tuner immediately adds index entries for thoseemployees while processing the query, thus causing latencyspikes. Furthermore, the tuner must maintain an additional datastructure (e.g., a covering tree [7]) for each index to keep trackof the indexed sub-domains, so that the DBMS can determineif it can process the query using the index.

We propose a value-agnostic partial scheme (VAP), where thetuner only adds entries for tuples contained in a fixed numberof pages at a time during each tuning cycle, irrespective ofthe value of the salary attribute in these tuples. With VAP,the DBMS can use an index to accelerate query processingwithout having to immediately populate the (t1, t2) sub-domain.This design ensures that the index construction overhead isindependent of the value distribution of the salary attribute.The DBMS reads the partially-built index for the alreadyindexed pages, and falls back to a table scan for the other pages.With VAP, the tuner does not need to maintain any additionaldata structures. Decoupling index construction from queryprocessing ensures that the tuner only performs lightweightphysical design changes, thereby preventing latency spikes. Wedefer a detailed description of this scheme to Section III.

We present a motivating experiment to illustrate the perfor-mance implications of employing these three different schemes.We load 10m tuples into the EMPLOYEE table whose salaryattribute is an integer value from a Zipf distribution in the range[1,1m] [15]. We configure the input parameters t1 and t2 inthe query’s predicate such that it selects 1% of the employees.We execute 5000 queries of the same query type with differentinput parameters.

The results are shown in the time series graph in Figure 2.We observe that with FULL, the query latency drops sharplyafter the tuner completely builds the index. Till then, the DBMSscans the table during query processing. With VBP, the querylatency follows a bimodal distribution. The latency matchesthat of an index scan when the query accesses an alreadyindexed sub-domain, but then degenerates to a table scan whenit retrieves tuples from a sub-domain that has not been indexedyet. In the latter case, the tuner immediately populates entries

INDEX USAGE MODE: FULL VALUE-BASED PARTIAL VALUE-AGNOSTIC PARTIAL

0 1000 2000 3000 4000 5000Query sequence

100

101

102

103

Late

ncy

(ms)

Fig. 2: Ad-hoc Index Usage Schemes – This time series graphillustrates the benefits of using a partially-built index during queryprocessing. While the query latency follows a bimodal distributionwith VBP, it gradually drops over time with VAP.

associated with the sub-domain in the index while processingthe query, thus causing latency spikes.

With VAP, the query latency gradually drops over time.This is because the tuner incrementally populates the indexover several tuning cycles, and the hybrid scan operatorincreasingly leverages it to skip scanning parts of the table. Akey observation from the time series graph is that VAP preventslatency spikes. After the tuner fully populates the index, theDBMS executes the query 10.1× faster than a table-scan. Thecumulative time taken by the DBMS to execute this workloadwith VAP is 1.6× and 3.2× shorter than that taken with theVBP and FULL schemes, respectively. The tuner periodicallypauses the tuning process to control the index constructionoverhead. The impact of the partial schemes (VAP and VBP)is more pronounced during such pauses, as they enable theDBMS to leverage the partially-built indexes.

The main issue with using a partially-built index is that sincethe tuner is dynamically populating the index, unless care istaken, the hybrid scan operator will return the same matchingtuple twice. Moreover, it may not be able to find a matchingtuple if that tuple has not yet been inserted into the index. Inthe next section, we describe how to solve these problems withour hybrid scan operator. We then present the predictive indextuner in Section IV.

III. HYBRID SCAN

The hybrid scan operator is a combination of an index andtable scan. We illustrate it using the query on the EMPLOYEEtable that contains nine tuples stored across three pages.Figure 1 shows the point when the tuner has finished indexingthe tuples contained in the first two pages, and is in the processof indexing the third page. It has indexed only the first tuple inthe third page, and suppose that this tuple satisfies the query’spredicate. While processing this query, the hybrid scan readsthe partially-built index to cover the first two pages and thenresorts to a table scan over the third page. It then returns thetuples retrieved using these two operations.

This design ensures that the DBMS finds all the tuplessatisfying the predicate because the operator covers every pageat least once when scanning the index and table. It can, however,still return the same matching tuple twice, if it is retrieved byboth operations. We next describe how hybrid scan removessuch duplicate tuples.

The DBMS assigns each page a unique page identifier (ρ).While populating an ad-hoc index on a table, the index tuner

INDEXSCAN

TABLESCAN

Page 1

Page 2

Page 4

Page 3

Page 5

Pm

Pi

(a) ρm = ρi

INDEXSCAN

TABLESCAN

Page 1

Page 2

Page 4

Page 3

Page 5

Pm

Pi

(b) ρm > ρi

INDEXSCAN

TABLESCAN

Page 1

Page 2

Page 4

Page 3

Page 5

Pm

Pi

(c) ρm < ρi

Fig. 3: Hybrid Scan Operator – Different scenarios depicting thepage from which the hybrid scan operator must start scanning thetable in order to ensure that it returns each matching tuple once andexactly once.

traverses its pages in ascending order with respect to the pageidentifier. During query processing, the hybrid scan operatorgoes over the pages in the same order. While scanning theindex, the operator keeps track of the identifiers of two pages:(1) the page with the largest identifier that contains a matchingtuple (ρm) and (2) the page with the largest identifier that hasalready been completely indexed (ρi).

When the index scan finishes, the operator determines thepage from where it should begin the table scan by computingmax(ρm, ρi +1). This is because, as shown in Figure 3, thereare only three possibilities: (1) ρm=ρi, (2) ρm>ρi, or (3) ρm<ρi.In all of these, starting the table scan from max(ρm, ρi + 1)ensures that it returns all matching tuples at least once. Onlywhen ρm > ρi, the operator additionally needs to removeduplicate tuples present in the overlapping page. The EMPLOYEEtable example illustrates this scenario. After the index scan,the operator first populates the matching tuples contained inthe overlapping third page in a sorted data structure. Then,during the subsequent table scan over the same page, it checksfor duplicate tuples using the sorted data structure, and skipsreturning them twice.

Concurrency Control & Updates: DBMS-X employsthe multi-version concurrency control (MVCC) protocol forscheduling transactions. The DBMS records the versioningmeta-data alongside each tuple, and uses it to determine whethera tuple version is visible to a transaction. While handlingupdates, it appends the modified tuple versions in the table.Since the tuner will subsequently index these tuples, the DBMSdoes not propagate the changes to the ad-hoc indexes built bythe tuner. The hybrid scan operator, therefore, reads updatesmade by concurrent transactions that are visible as per theMVCC protocol during its table scan. This design allowsthe hybrid scan operator to work well on a wide variety ofHTAP workloads, including those containing long-running scanqueries.

Query Optimization: We now describe how we extendedthe query optimizer to use hybrid scan. DBMS-X’s optimizerexamines the query’s predicates and the access paths availableon its referenced tables, and estimates a cost for each plan [16,17]. It uses a hybrid scan access path similar to how it employs

an index scan access path. It picks a hybrid scan only forprocessing high selectivity queries, and switches to a tablescan otherwise.

A. Value-Agnostic & Value-Based Scan

The value-agnostic hybrid scan operator differs from thevalue-based operator employed by prior indexing approaches [4,6, 7]. With the value-agnostic operator, the tuner can bettercontrol the index construction overhead. It incrementallypopulates the index by adding entries only for a fixed numberof pages at a time. This decouples the indexing overhead fromthe value distributions of the attributes being indexed. Thepartially-built index only needs to keep track of the numberof pages that have already been fully indexed, so that theoperator can determine the page from which it must begin thetable scan operation. The main limitation of the value-agnosticoperator is that the query processing time drops linearly overtime, unlike the logarithmic drop observed with the value-basedoperator [6, 18].

With the value-based operator, after the tuner completelypopulates a sub-domain of an index, it can skip the table scanoperation while handling subsequent queries for the indexedsub-domain. This shrinks the query processing time but causeslatency spikes when the size of the sub-domain accessed islarge. As such, the tuner may not be able to react in time tofuture workload shifts. Further, the index must maintain meta-data about the sub-domains that have already been indexed, sothat the operator can safely skip the table scan operation whenscanning indexed sub-domains. To prevent latency spikes, wetherefore employ the value-agnostic operator. We note that bothhybrid scan operators help shrink the adaptation time of theDBMS in comparison to the FULL scheme employed by onlineindexing approaches [12, 13]. This is because they enable theDBMS to immediately make use of partially-built indexes.

IV. PREDICTIVE DECISION LOGIC

We next present how the tuner’s predictive DL decreases itsdetection time. The complexity of the index tuning problem canbe attributed to two factors [8]. First, the tuner must balancethe performance gains of an index during query processingagainst the overhead of maintaining it while executing queriesthat update the index. The tuner must, therefore, adapt theindex configuration based on the current workload mixture. Ona read-intensive workload, it should build additional indexes foraccelerating query processing. But when the workload shifts towrite-intensive queries, it should drop a subset of these indexesto reduce the index maintenance costs.

Second, the tuner must take the storage space consumed bythe index into consideration. This is an important constrainteven when there are no updates. Indexes typically consumea significant portion of the total memory footprint of theDBMS, particularly on OLTP workloads. This is because OLTPapplications often maintain several indexes per table to ensurethat the queries execute quickly. For instance, a previous studyfound that indexes consume more than half of the storage spaceused by an in-memory DBMS for OLTP workloads [19]. The

Algorithm 1 Predictive Indexing AlgorithmRequire: Recent queries Q (R andW), Index configuration I, Index

storage budget S# Executed once during every tuning cyclefunction EVOLVE-INDEX-CONFIGURATION(Q, I,S)

# Stage I : Workload classificationLabel L = Workload-Classifier(Q)# Stage II : Action GenerationCandidate indexes C = Candidate-Indexes(Q)Overall utility O = Overall-Utility(I, C, Q)Index configuration I′ = Index-Knapsack(L, S, I, C, U , O)Apply lightweight changes to reach index configuration I′# Stage III : Index Utility ForecastingForecasted utility U = Holt-Winters-Forecaster(U , O)

end function

SCAN QUERY RATIO < β1

WRITE-INTENSIVE

TUPLES READ FROM

INDEXES> β2

YES

NO

YES

NO

TUPLES SCANNED

< β3

YES

NO

WRITE-INTENSIVE WRITE-

INTENSIVE

READ-INTENSIVE

Fig. 4: Workload Classifier – The pruned decision tree used by thetuner to determine the type of the query workload.

tuner must, therefore, ensure that the indexes fit within theavailable memory.

The predictive machine-learning (ML) model contains threeprincipal components: (1) workload classifier, (2) actiongenerator, and (3) index utility forecaster. These componentsperform the three steps that correspond to the observe-react-learn template that an agent typically follows in reinforcement-learning [20]. Algorithm 1 presents an overview of thepredictive indexing algorithm.

During every index tuning cycle, the classifier examines therecent query workload that is tracked by a lightweight workloadmonitor, and determines the type of the workload [21–23].Based on the workload classification, the recently executedqueries, the utility of the indexes present in the currentindex configuration, and the recent query workload, the actiongenerator performs a set of actions, that involve building anddropping indexes. These actions change the index configurationof the DBMS, and the utility of this state transition is fed backas input by the index utility forecaster to the action generator asthe reinforcement signal [20]. Through this systematic trial-and-error, the tuner learns to choose actions that increase the utilityof the index configuration, thereby improving the performanceof the DBMS. We next describe these three model componentsin further detail.

A. Workload Classification

The type of the DBMS’s current query workload is animportant consideration for the index tuning process. This isbecause the benefits of an index during the workload’s read-intensive phases could be outweighed by the cost of maintainingit during the write-intensive phases. The tuner constructs anindex only when it expects it to be beneficial for the currentand near-future workloads.

We construct a workload classifier in the form of a decisiontree using the classification and regression tree (CART)algorithm [24]. This algorithm constructs a binary tree, whereeach node contains a feature and threshold that yields thelargest information gain. We train the classifier using workloadsnapshots collected by running a set of OLTP and OLAPbenchmarks in DBMS-X [25]. Each snapshot contains meta-data about k recently executed queries, and is manuallyassigned a classification label. The collected meta-data containsa set of domain-specific features, such as ratio of the numberof SELECT statements to that of UPDATE, INSERT, and DELETEstatements [26]. We construct a training set of snapshots thatare each assigned one of the following labels:

• Write-Intensive: The workload is characterized by alarge number of short on-line transactions that mutatethe database. The maintenance cost of an ad-hoc indexmight outweigh its benefits during query processing onthis type of workload.

• Read-Intensive: The workload is characterized by a smallnumber of complex read-only queries that often involveaggregations. The benefits of ad-hoc indexes is oftengreater than the index maintenance overhead on this typeof workload.

We use a decision tree for the classifier because it is bettersuited for this classification task compared to other ML tech-niques by virtue of its interpretability; it is easier to understandthe classification rules and explain the classifier’s decisions.Based on our domain-specific knowledge, we configure theDBMS’s monitor to collect the following features in everyworkload snapshot:

• Ratio of scan queries to mutators: The ratio of the num-ber of SELECT to UPDATE, INSERT, and DELETE statements.

• Ratio of tuples accessed using indexes: The ratio oftuples that are accessed via indexes rather than directlyfrom the table. It tends to be higher for write-intensiveworkloads.• Number of tuples scanned: The average number of tuples

scanned (higher for read-intensive workloads).

Figure 4 presents the pruned decision tree for workloadclassification. The higher-level nodes in the decision tree corre-spond to features that are more important in the classificationprocess. The ratio of queries to mutators is the crucial featurefor workload classification. It is important to not take featuresthat are dependent on the system utilization and databaseconfiguration into consideration, such as metrics like systemthroughput and cache hit ratio.

The tuner uses the classifier during each tuning cycle todetermine the current query workload type. Based on thisclassification, it determines how to next evolve the indexconfiguration. If it detects a write-intensive workload, it prunesthe configuration by dropping ad-hoc indexes of low utility1.

1The tuner assigns high utility values to indexes that are used for processingUPDATE statements even in a write-intensive workload, and will thus refrainfrom dropping them.

In contrast, if the classifier detects a read-intensive workload,then the tuner expands the configuration by building auxiliaryindexes to accelerate the analytical queries. The classifier onlyemits classifications that are supported by a minimum thresholdof query samples. This ensures that it is robust during periodsof low system utilization. We next describe how the tunergenerates actions for mutating the index configuration.

B. Action Generation

The action generator picks the actions that need to be takento improve the performance of the DBMS. These actions couldeither involve building an index or dropping an existing index.We note that the following discussion is relevant for bothprimary and secondary indexes. The generator picks theseactions based on the current workload classification, the recentlyexecuted queries, and the utility of the indexes present in thecurrent index configuration. These actions mutate the indexconfiguration of the DBMS, and the value of this state transitionis later estimated by the forecaster.

The lightweight workload monitor tracks the attributes thatare accessed by each query. The goal is to determine the setof attributes present in the statement predicates and clausesthat should be indexed by an ad-hoc index. In particular,it keeps track of the attributes appearing in equal, range,and join predicates, the attributes present in GROUP BY andORDER BY clauses, and the remaining attributes referenced inthe SQL statement. The monitor stores this information foreach individual table. The generator then uses this informationto enumerate various combinations of these attribute sets,and determines the set of candidate indexes that are notpresent in the current index configuration [12]. The set ofcandidate indexes includes both single-attribute and multi-attribute indexes. We next describe our methodology forcomputing the utility of an index.

Query Processing Utility: The tuner uses the query opti-mizer to obtain the estimated processing cost of a given queryin the presence and absence of a candidate index [12, 27]. Werefer to the difference between the costs of executing a queryin the presence and absence of an index as its query processingutility (QPU). The tuner uses this information to determinewhether it should construct a particular candidate index or not.QPU of a candidate index I is derived by evaluating its impacton the set of scan queries R in the latest workload snapshotwhose underlying table scans can be accelerated using I. Letus denote the cost of processing a query r using only theexisting indexes as η(r), and let η(r, I) represent the cost ofprocessing the same query using I in addition to the existingindexes (η(r) ≥ η(r, I)). Then, QPU of I is represented by:

QPU(I,R) =∑r∈R

(η(r)− η(r, I))

Index Maintenance Cost: The tuner next considers theoverhead of maintaining the candidate and currently builtindexes while executing statements that mutate the index. Werefer to this overhead as the index maintenance cost (IMC).

This is crucial for the DBMS to perform well on write-intensiveworkloads. For each index, the tuner keeps track of the queriesW that update, insert, or delete entries in the index. Let usdenote the cost of maintaining an index I while processing aquery w by τ (w, I). The IMC of I is represented by:

IMC(I,W) =∑w∈W

τ(w, I)

The overall utility of an index is obtained by discountingthe index maintenance cost from the query processing utilityof an index:

Overall Utility(I,R,W) = QPU(I,R)− IMC(I,W)

Index Knapsack Problem: After determining the overallutility of the candidate and current indexes, as shown inAlgorithm 1, the tuner constructs a subset of the candidateindexes and drops a subset of the currently built indexes,after taking their storage footprint into consideration. We canformulate it as a 0-1 knapsack problem [28]. Let C represent theset of candidate and currently built indexes. The set of candidateindexes includes: (1) indexes that are expected to speed upqueries in the near future by the index utility forecaster, and(2) indexes that accelerate newly encountered queries whosetrends have not yet been captured by the forecaster. For thelatter subset, we bootstrap the utility of these indexes in theforecaster’s model with their overall utility, as illustrated inAlgorithm 1. The tuner dampens the utility of redundant indexeswith correlated attributes by characterizing their interactions [3].

By capturing the index utility patterns, the forecaster enablesthe tuner to look ahead into the future and optimistically buildindexes. Let us assume that each index c ∈ C has a utilityUc ≥ 0 and an estimated storage footprint Sc ≥ 0. For newlysuggested indexes, Uc refers to the overall utility. In case ofindexes that are either currently built or existed in the past,it represents the forecasted utility. Let B denote the storagespace available for storing indexes. Then, the solution of theknapsack problem is a subset of indexes C′ ⊆ C with maximalutility:

maximize∑c∈C′

Uc such that∑c∈C′

Sc ≤ B

Index Configuration Transition: Based on the classifica-tion by the workload classifier presented in Section IV-A,the tuner determines the minimum utility (Umin) requiredfor an index to exist. It scales up Umin while handlinga write-intensive workload, and scales it down on a read-intensive workload. After determining the indexes to add anddrop, the action generator applies those changes in the indexconfiguration. We refer to this step as a state transition towardsthe desired final index configuration state. The tuner amortizesthe overhead of this state transition over a set of tuning cyclesto ensure that the DBMS’s performance is predictable.

C. Index Utility Forecasting

The final component of the tuner is the index utility forecasterwhich predicts the utility of indexes in the near future. As shown

TREND: ACTUAL UTILITY FORECASTED UTILITY

0 30 60 90 120 150 180 210 240 270 300Tuning Period

0.0

0.5

1.0

Inde

xU

tility

Fig. 5: Learning Utility – Forecasting index utility using the Holt-Winters method with multiplicative seasonality.

in Algorithm 1, the forecasted utility of the index configurationafter the state transition is fed back as input to the actiongenerator during the next tuning cycle. Using this feedback,the tuner learns to pick actions that increase the long-run sumof the reinforcement signal, which is the overall utility of theindex configuration.

Holt-Winters Seasonal Method: To forecast the utility ofthe indexes, the tuner uses a variant of exponential smoothing.This method predicts the index utility by computing a weightedaverage of past utility observations with the weights decayingexponentially as the observations get older. The Holt-Wintersseasonal method extends the basic exponential smoothingtechnique to allow forecasting of data with a trend besidescapturing seasonality [29, 30]. This method is comprised ofthe forecast equation along with three smoothing equations.The three smoothing equations estimate the level lt, the trendbt, and the seasonal component st of a time series.

Forecast equation: yt+h|t = (lt + hbt)st−m+hm

Level equation: lt = α(yt/st−m) + (1− α)(lt−1 + bt−1)

Trend equation: bt = β(lt − lt−1) + (1− β)bt−1Seasonal equation: st = γ(yt/(lt−1 + bt−1)) + (1− γ)st−m

Here, α, β, and γ are the smoothing parameters for theutility level, trend, and seasonality respectively, and α, β, γ ∈[0, 1]. m denotes the period of the seasonality.

Using the forecast equation, the tuner predicts the utilityof indexes in the near future after factoring in the trend andseasonality aspects of the time series, as shown in Figure 5.The accuracy of the forecaster’s predictions with respect to anindex increases over time as it obtains more observations. TheHolt-Winters method dampens the utility of indexes that arenot beneficial in the recent past. Over time, the tuner drops theless useful indexes to make space for building new indexes thatare more useful during query processing. Even after droppingan index, the tuner’s forecaster retains the model meta-dataassociated with that index. This allows it to predict that index’sutility in future when it is requested by the action generator.

We next describe the design of the benchmark that we usefor evaluating predictive indexing.

V. TUNER BENCHMARK

We developed a new open-source benchmarking suite toevaluate the efficacy of predictive indexing with respect to otheronline indexing approaches. The queries in this benchmarkare derived from a HTAP workload in a bus tracking mobile

application [9]. The TUNER benchmark extends prior physicaldesign tuning benchmarking suites proposed in [11, 31, 32] inthree ways. It examines the impact of the index tuner underboth regular and heavy system loads, when the tuner throttlesits tuning frequency to cope with workload spikes. Second, itevaluates the impact of automatically adapting both the storagelayout and the index configuration of the database in tandem,thus focusing on two key components of the physical designproblem. Lastly, it characterizes the predictive index tuner’sability to leverage idle system resources.

The TUNER database contains two tables: a narrow table anda wide table. Each table contains tuples with a timestamp (a0)and p integer attributes (a1, . . . , ap), each 4 bytes in size. Thenarrow table has p = 20 attributes, and the wide table has p =200 attributes. Each attribute ak is an integer value from a Zipfdistribution in the range [1, 1m]. The benchmark can configurethe selectivity of the predicates in a query while constructingmulti-attribute range and equality predicates present in themobile application’s HTAP workload. We next describe ourmethodology for constructing these queries that filter andaggregate the dataset based on different attribute sets.

A. Query Generation

We construct workloads using two kinds of queries: (1) scanqueries and (2) update queries.

Scan Queries: We use three SELECT templates to constructqueries with different levels of workload complexity:

• Low-Complexity Scan (LOW-S): It computes aggregatesover a single table after applying a comparison predicatedefined on a single attribute. This query templaterepresents the simplest scenario for an index tuner.

SELECT a1,a2 + a3,. . .,SUM(ak) FROM RWHERE ai ≥ δ1 AND ai ≤ δ2

• Moderate-Complexity Scan (MOD-S): It is similarto the previous template except that the comparisonpredicate is now defined on a combination of attributes.The tuner must build multi-attribute indexes to acceleratesuch queries.

SELECT a1,a2 + a3,. . ., SUM(ak) FROM RWHERE ai ≥ δ1 AND ai ≤ δ2 AND aj ≥ δ3 ANDaj ≤ δ4

• High-Complexity Scan (HIGH-S): Unlike the previousquery templates, this query contains an equi-join operationover two relations in addition to the multi-attributecomparison predicates. The query would, therefore,benefit from the presence of indexes defined on theattributes involved in the join predicate.SELECT X.a1,. . .,X.ak, Y.a1,. . .,Y.akFROM X, YWHERE X.ai ≥ δ1 AND X.ai ≤ δ2 ANDAND Y.aj ≤ δ4 AND X.al = Y.am

We vary the selectivity and projectivity of the predicates inthe scan queries by altering δ1, δ2, and k.

Update Queries: We use three different query templates toconstruct updates and inserts that correspond to different levelsof workload complexity. These include:

• Low-Complexity Update (LOW-U): It updates arandom subset of attributes for tuples that satisfy acomparison predicate defined on a single attribute.UPDATE R SET a1=v1,a2=v2,. . .,ak=vk + 1WHERE ai ≥ δ1 AND ai ≤ δ2

• High-Complexity Update (HIGH-U): It is similar to thelow-complexity update query except that the comparisonpredicate is now defined on a combination of attributes.UPDATE R SET a1=v1,a2=v2,. . .,ak=ak + 1WHERE ai ≥ δ1 AND ai ≤ δ2 AND aj ≥ δ3 ANDaj ≤ δ4

• Insert (INS): It inserts a set of tuples into the table.Unlike the UPDATE statement that involves both table scanand modifications, INSERT statement only performs tablemodifications.INSERT INTO R VALUES (a0, a1, . . . , ap)

B. Workload Generation

We use the above queries to construct a set of workloads thatexercise different aspects of predictive indexing. A workloadis a sequence of queries with changing properties. To clearlydelineate the impact of the index configuration on the differentqueries, we divide a sequence into phases consisting of a fixednumber of queries that each correspond to a particular querytype. This means that the DBMS executes the same querytype (with different input parameters) in one phase, and thenswitches to another one in the next phase.

Tuning Frequency: The benchmark examines the tuner’simpact when it only operates during certain time periods. Thetuner usually runs frequently, and is likely to react quicker toshort-lived workload shifts. In contrast, when the load is high,it runs less frequently and is likely to treat these ephemeralshifts as noise, and demonstrates gains only on longer phases.The benchmark examines the tuner’s impact when it operatesunder four different frequencies: FAST, MOD, SLOW, and DIS.With the FAST, MOD, and SLOW configurations, the tuner runson average once every 100, 1000, and 10000 ms. Index tuningis disabled with DIS, and serves as a baseline.

Shifting Workloads: We construct shifting workloads ofdifferent phase lengths to examine how swiftly can the tuneradapt to these shifts. If the total number of queries in a workloadis t, and the phase length is l, then the workload is comprisedof t

l phases. The performance impact of tuning depends on theaverage phase length of the workload. Stable workloads withlonger phases benefit more from tuning. This is because afterthe tuner observes a set of queries based on a query template,it builds an index to accelerate query processing. Subsequent

queries of the same template would also be accelerated.

Hybrid Workloads: To evaluate the ability of the tunerto handle both scan and update queries, we construct hybridworkloads wherein the tuner must factor in both the queryprocessing utility and the maintenance cost of indexes. Weconstruct four types of workload mixtures that vary theoperations that the DBMS executes. These mixtures representdifferent ratios of scans and updates:

• Read-Only: 100% scans

• Read-Heavy: 90% scans, 10% updates

• Balanced: 50% scans, 50% updates

• Write-Heavy: 10% scans, 90% updates

On the read-intensive mixtures, the DBMS benefits from theconstruction of ad-hoc indexes that accelerate query processing.The benefits are not as pronounced on the write-intensivemixtures due to index maintenance costs. We construct theupdates using the UPDATE query templates, and configure thescans to be low-complexity queries.

VI. EXPERIMENTAL EVALUATION

We now present an analysis of our predictive indexingapproach using DBMS-X [9]. DBMS-X is an in-memoryMVCC DBMS that supports HTAP workloads. We integratedour index tuner as a background thread that runs periodicallydepending on the tuning frequency. It decides both when andhow to adapt the index configuration. During every tuningcycle, it classifies the workload, generates and applies physicaldesign changes, and learns the utility of these changes. Weextended the system’s execution engine and query optimizerto support the value-agnostic hybrid scan operator. To performa comparative evaluation, we integrated different indexingapproaches in DBMS-X, including (1) online [3, 5], (2)adaptive [6], (3) self-managing [7], and (4) holistic [4].

We deployed DBMS-X on a dual-socket Intel Xeon E5-4620server running Ubuntu 14.04 (64-bit). Each socket containseight 2.6 GHz cores. It has 128 GB of DRAM and 20 MB ofL3 cache. For each experiment, we execute the workload fivetimes and report an average of the metrics. All transactions areexecuted with the default snapshot isolation level. We disablelogging to ensure that our measurements only reflect queryprocessing time. Each table in the TUNER database contains10m tuples, and the total size of the database is 8.8 GB.

We begin with an analysis of the ability of the tunerto recognize workload trends using its forecaster. We theninvestigate the benefits of using hybrid scan to leverage partiallybuilt indexes. Next, we compare our tuner against the holisticindexing approach on a HTAP workload. We then demonstratehow the index tuner works seamlessly with the storage layouttuner in DBMS-X. Lastly, we present an analysis of the tuner’sability to adapt to shifting workloads.

A. Decision Logic

We use a HTAP workload to examine the ability of thetuner to recognize workload trends and adapt the index

DECISION LOGIC: RETROSPECTIVE IMMEDIATE PREDICTIVE

0 500 1000 1500 2000 2500 3000 3500 4000 4500 50000

150

300

Late

ncy

(ms)

0 500 1000 1500 2000 2500 3000 3500 4000 4500 50000

150

300

Late

ncy

(ms)

0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000Query Sequence

0

150

300

Late

ncy

(ms)

Fig. 6: Decision Logic – Reaction times of the index tuner whenusing different types of decision logic for a HTAP workload.

configuration ahead of time. This workload contains 5000moderate complexity scan queries with a phase length of500 queries. We throttle the client request throughput at thebeginning of each phase to evaluate the tuner’s ability toleverage idle system resources while it employs different typesof decision logic: (1) retrospective DL, (2) predictive DL, and(3) immediate DL. We note that the index tuner must constructmulti-attribute indexes to accelerate the processing of these scanqueries. Most of the queries contain the same multi-attributepredicate, and will thus benefit from the same index. A smallfraction (1%) of the queries are noisy queries containing otherpredicates. Ideally, the tuner should recognize that it is notuseful to build indexes to accelerate such queries. We drop allthe built indexes at the end of each phase. This is meant tomodel a diurnal workload where indexes have to be rebuiltevery morning.

The key observation from Figure 6 is that with predictiveDL, the tuner’s forecaster captures the query pattern afterobserving 1500 queries. It then makes use of idle systemresources at the beginning of each phase to build the indexahead of time, thus allowing the DBMS to start using the indexearlier within the phase. With retrospective DL, the tuner onlyexamines the recent k queries in the same phase, and does notproactively build indexes. This increases the tuner’s detectiontime, and it finishes index construction only later in the phase.Retrospective DL still guards against noisy queries. In contrast,with immediate DL, the tuner constructs indexes to acceleratethese noisy queries, thereby slowing down the overall indexconstruction speed and increasing the adaptation time. Thecumulative time taken by the DBMS to execute this workloadwith predictive DL is 5.2× and 3.5× shorter than that takenwith the retrospective and immediate schemes, respectively.This experiment shows that predictive DL can both shrink thedetection time of the tuner and guard against noisy queries.

B. Hybrid Scan

We next examine the performance impact of differentapproaches for leveraging a partially-built index: FULL, VAP, andVBP. We consider three workloads with varying affinity levelswith respect to the index sub-domains accessed by the queries:(1) very high, (2) high, and (3) moderate levels. Queries inworkloads with higher affinity levels target a smaller number ofsub-domains. The workloads contain 5000 moderate complexity

INDEX TUNING MODES: HOLISTIC PREDICTIVE

0 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 11000 12000 13000 14000 15000Query Sequence

110

1001000

10000La

tenc

y(m

s)Scan (Copying) Scan (Proactive) Insert (Dropping)

Fig. 7: Holistic Indexing – Comparison of the performance impact of the holistic and the predictive indexing approaches on a HTAPworkload.

INDEX USAGE MODE: FULL VALUE-BASED PARTIAL VALUE-AGNOSTIC PARTIAL

0 500 1000 1500 2000 2500 3000 3500 4000 4500 50000

150

300

Late

ncy

(ms)

% OF INDEX BUILT: 100%AFFINITY LEVEL: ALL

0 500 1000 1500 2000 2500 3000 3500 4000 4500 50000

150

300

Late

ncy

(ms)

% OF INDEX BUILT: 100%AFFINITY LEVEL: ALL

0 500 1000 1500 2000 2500 3000 3500 4000 4500 50000

150

300

Late

ncy

(ms)

% OF INDEX BUILT: 4%AFFINITY LEVEL: VERY HIGH

0 500 1000 1500 2000 2500 3000 3500 4000 4500 50000

150

300

Late

ncy

(ms)

% OF INDEX BUILT: 10%AFFINITY LEVEL: HIGH

0 500 1000 1500 2000 2500 3000 3500 4000 4500 5000Query Sequence

0

150

300

Late

ncy

(ms)

% OF INDEX BUILT: 20%AFFINITY LEVEL: MODERATE

Fig. 8: Hybrid Scan Operators – Comparison of the performanceimpact of the different approaches for leveraging partially-built indexes.

scan queries with a phase length of 500 queries. We configurethe number of different sub-domains accessed by the queriesto be 2, 5, and 10 to create workloads with varying affinitylevels. We construct a variant of VBP that prevents latencyspikes by decoupling index construction from query processing.With this scheme, the tuner incrementally populates entriesassociated with a sub-domain over several tuning cycles, insteadof immediately adding all the entries.

The results in Figure 8 show that unlike VBP, the behavior ofVAP and FULL is unchanged on workloads with different affinitylevels. This is because with VBP, the DBMS can leverage thepartially-built index only when the sub-domain accessed by thequery has been already indexed. But VAP enables the DBMSto make use of the partially-built index irrespective of thesub-domain accessed by the query.

The cumulative time taken to execute the workloads withmoderate and high affinity levels with VAP is 3.1× and 1.7×shorter than that taken with VBP, respectively. This is because,unlike VBP, VAP can accelerate query processing even onworkloads with lower affinity levels. On the very high affinitylevel workload, VAP tuner takes 1.05× longer than that takenwith VBP. This is because the VBP tuner populates the frequentlyaccessed sub-domains faster than VAP. We observe that withVBP and FULL, the index is fully populated near the end ofthe workload. In contrast, with VAP, only 4%, 10%, and 20%of the index is built depending on the number of differentsub-domains accessed in the workload. The key observation

from this experiment is that VAP allows the DBMS to leveragethe index even when the sub-domain is not yet completelyindexed.

C. Holistic Indexing

We now demonstrate how predictive indexing improves theperformance of the DBMS in comparison to holistic indexing.Holistic indexing is an always-on VBP scheme where the tuneroptimistically chooses which indexes to build next and thenpopulates them when the DBMS is idle [4]. Although predictiveindexing shares many of the goals of holistic indexing, it differsin three ways. It employs a value-agnostic hybrid scan operatorinstead of a value-based one. It adopts a predictive DL insteadof an immediate DL. Lastly, it decouples index constructionfrom query processing. For this experiment, we implementedholistic indexing with a random index selection strategy inDBMS-X and compare it against our approach [4]. We run aworkload consisting of three segments, each of which contains5000 queries based on multiple query templates. The first twosegments consist of scan queries of moderate complexity, whilethe last one contains insert queries.

The results in Figure 7 show that on the first segmentwith holistic indexing, there are latency spikes that are ashigh as 4× the latency of a table scan. When the tunerencounters a query accessing a sub-domain that has not yetbeen indexed, it immediately starts indexing it while processingthe query [6]. Although this approach accelerates the executionof subsequent queries with the same template, it involvesheavyweight physical design changes. In contrast, we do notobserve such spikes with predictive indexing, since it amortizesthe index construction overhead across several tuning cycles.

To leverage idle system resources, holistic indexing advocatesa proactive approach towards building indexes even on attributesthat have not been queried yet [4]. This can, however, increasethe overall index construction overhead, and thereby causelatency spikes during subsequent query processing. Thisis illustrated during the second scan segment in Figure 7.Predictive DL mitigates this problem by populating indexeson attributes only after observing several queries that accessthem.

Lastly, on the third segment comprising of insert queries,the predictive tuner’s classifier detects the workload shift, andits action generator periodically drops indexes of limited utilityover time. This shrinks the insert query’s latency, as the DBMSneeds to update fewer indexes. The holistic tuner does not dropany indexes since (by design) it drops them only when they

TUNING MODES: DISABLED INDEX LAYOUT BOTH

Proj.=1%, Sel.=1% Proj.=1%, Sel.=10% Proj.=10%, Sel.=1% Proj.=10%, Sel.=10%Tuning Mode

0

175000

350000

Tota

ltim

e(m

s)

Fig. 9: Storage Layout & Index Tuning – The impact of indextuning in tandem with storage layout tuning on the query processingperformance.

exceed its storage budget. The cumulative time taken to executethis workload with predictive indexing is 7.7× shorter thanthat taken with holistic indexing.

D. Storage Layout & Index Tuning

This experiment examines the ability of the index tunerto work with other physical design tuners. We investigate theimpact of the index tuner when used in tandem with the storagelayout tuner. This layout tuner accelerates query executionby co-locating the attributes accessed together in a query inmemory [32, 33]. This enables the DBMS to make better useof memory bandwidth by fetching only the relevant attributesduring query processing. We evaluate four tuning modes tomeasure the impact of index and layout tuning on the system’sperformance:

• Disabled: Both index and layout tuning are disabled.• Index: Only index tuning is enabled.• Layout: Only layout tuning is enabled.• Both: Both index and layout tuning are enabled.

We consider the behavior of the layout and index tunersunder different projectivity and selectivity settings on a read-only workload comprising of moderate-complexity scan querieson the wide table. We vary both the projectivity and selectivityof scan query from 1% to 10%. We measure the total timetaken by the DBMS to execute the workload, including thetime spent on tuning the layout and index configuration.

The results in Figure 9 show that the index and layout tunerstogether are able to reduce the workload’s execution time morethan that what they accomplish independently. Under highprojectivity and selectivity settings, we observe that while indexand layout tuning independently speed up query execution by1.9× and 1.5×, respectively, they reduce query execution timeby 2.7× when used in tandem. The layout tuner incrementallymorphs the table to a hybrid storage that collocates the query’sprojection attributes. On average, the layout tuner takes 2.6 msto transform the layout of a page containing 1000 tuples.Concurrently, the index tuner incrementally builds indexesto quickly retrieve the matching tuples. During one iterationof Algorithm 1, the index tuner takes on average 5.2 ms topopulate a set of indexes with entries associated with a page.

The impact of the tuners is more prominent under lowprojectivity and selectivity settings, as shown in Figure 9. Inthis case, index and layout tuning together shrink the executiontime by 7.8×. We attribute this to the higher gains from indexand layout tuning when 1% of the attributes and 1% of the

TUNING FREQUENCY: FAST MODERATE SLOW DISABLED

50 100 250 500Phase Lengths

0

45000

90000

Exe

cutio

ntim

e(m

s)

(a) Read Only

50 100 250 500Phase Lengths

0

45000

90000

Exe

cutio

ntim

e(m

s)

(b) Write Heavy

Fig. 10: Tuner Adaptability – The impact of the index tuning onthe query processing time under different phase length settings. Theexecution engine runs different workload mixtures, each comprisingof scan queries of varying complexity, on the narrow table.

tuples are respectively projected and selected from the table.This highlights the importance of continuously improving thephysical design of the DBMS using many small steps.

E. Tuner Adaptability

We next analyze how the tuner adapts to shifting HTAPworkloads. We examine the impact of the tuner when operatingunder four different tuning frequencies: FAST, MOD, SLOW,and DIS. We consider two workload mixtures, each comprisingof 5000 queries, and we vary the phase length of the workloadfrom 50 to 500 queries.

Figures 10a and 10b show the results for the read-only andwrite-heavy workloads under different phase length settings.The most notable observation is that the benefits are greateron workloads with longer phases. When the phase length is500 queries, FAST outperforms DIS by 3.4×. This is becauseafter the tuner constructs the appropriate index in a phase, allthe subsequent queries within the same phase benefit from theindex. We observe that MOD and SLOW outperform DIS by2.6× and 1.6×, respectively. The impact of the tuner is lessprominent under these configurations because it takes moretime to build the indexes due to lower tuning frequencies.

VII. RELATED WORK

The design of predictive indexing benefited from prior workon online index tuners, offline index advisors, self-managingindexing, and holistic indexing.

Online Index Tuners: The problem of automatically tuningthe index configuration of a database to improve its performanceon evolving query workloads has been studied for severaldecades [34]. More recently, Bruno and Chaudhuri presentan online algorithm that dampens physical design oscillationsand takes index interactions into consideration [3]. COLT isan online index-tuning framework that dynamically lowers itsoverhead when the system has converged to an optimal indexconfiguration [5]. All of this work present tuners that leveragethe indexes during query processing only after fully populatingthem. In contrast, DBMS-X uses the index with the hybridscan operator even before it is fully built, thereby improvingits reaction time.

Self-Managing Indexing: Self-managing indexing (SMIX)is a VBP scheme that can dynamically expand and shrinkindexes based on the workload [7]. Unlike adaptive indexingthat incrementally converges to a full index, SMIX also shrinks

the index by dropping less frequently accessed entries. However,SMIX only refines indexes during query processing and adoptsan immediate DL. This can cause latency spikes and increasesthe reaction time. Unlike predictive indexing, it does not supportrange queries.

VIII. CONCLUSION

This paper presented predictive indexing that uses rein-forcement learning to predict the utility of indexes, andcontinuously refines the index configuration of the database tohandle evolving HTAP workloads. We proposed a lightweightvalue-agnostic hybrid scan operator that allows the DBMSto leverage partially-built indexes during query processing.Our evaluation showed that the predictive index tuner learnsover time to choose physical design changes that increase theoverall utility of the index configuration. We demonstratedthat the index and storage layout tuners in DBMS-X work intandem to incrementally optimize two key components of thedatabase’s physical design without requiring any manual tuning.Our evaluation showed that predictive indexing improves thethroughput of DBMS-X on HTAP workloads by 3.5–5.2×compared to other state-of-the-art indexing approaches.

REFERENCES

[1] S. Chaudhuri and V. R. Narasayya, “An efficient cost-drivenindex selection tool for microsoft sql server,” in VLDB, 1997,pp. 146–155.

[2] D. C. Zilio, J. Rao, S. Lightstone, G. Lohman, A. Storm,C. Garcia-Arellano, and S. Fadden, “DB2 design advisor:Integrated automatic physical database design,” in VLDB, 2004,pp. 1087–1097.

[3] N. Bruno and S. Chaudhuri, “An online approach to physicaldesign tuning,” in ICDE, 2007.

[4] E. Petraki, S. Idreos, and S. Manegold, “Holistic indexing inmain-memory column-stores,” in SIGMOD, 2015, pp.1153–1166.

[5] K. Schnaitter, S. Abiteboul, T. Milo, and N. Polyzotis, “COLT:Continuous on-line tuning,” in SIGMOD, 2006, pp. 793–795.

[6] S. Idreos, M. L. Kersten, and S. Manegold, “Databasecracking,” in CIDR, 2007.

[7] H. Voigt, T. Kissinger, and W. Lehner, “SMIX: self-managingindexes for dynamic workloads,” in SSDBM, 2013, pp.24:1–24:12.

[8] S. Finkelstein, M. Schkolnick, and P. Tiberio, “Physicaldatabase design for relational databases,” ACM TODS, pp.91–128, 1988.

[9] “Peloton Database Management System,” http://pelotondb.org.[10] S. Agrawal, E. Chu, and V. Narasayya, “Automatic physical

design tuning: workload as a sequence,” in SIGMOD, 2006.[11] K. Schnaitter and N. Polyzotis, “A benchmark for online index

selection,” in ICDE, 2009, pp. 1701–1708.[12] G. Valentin, M. Zuliani, and D. C. Zilio, “DB2 advisor: An

optimizer smart enough to recommend its own indexes,” inICDE, 2000.

[13] S. Chaudhuri and V. Narasayya, “Microsoft index turningwizard for SQL Server 7.0,” in SIGMOD, 1998, pp. 553–554.

[14] K.-U. Sattler, I. Geist, and E. Schallehn, “Quiet: Continuousquery-driven index tuning,” in VLDB, 2003, pp. 1129–1132.

[15] “Zipf Distribution,”http://mathworld.wolfram.com/ZipfDistribution.html.

[16] P. G. Selinger, M. M. Astrahan, D. D. Chamberlin, R. A. Lorie,and T. G. Price, “Access path selection in a relational databasemanagement system,” in SIGMOD, 1979, pp. 23–34.

[17] M. A. Soliman et al., “Orca: a modular query optimizerarchitecture for big data,” in SIGMOD, 2014, pp. 337–348.

[18] M. Athanassoulis, M. S. Kester, L. M. Maas, R. Stoica,S. Idreos, A. Ailamaki, and M. Callaghan, “Designing accessmethods: The rum conjecture.”

[19] H. Zhang, D. G. Andersen, A. Pavlo, M. Kaminsky, L. Ma, andR. Shen, “Reducing the storage overhead of main-memoryOLTP databases with hybrid indexes,” in SIGMOD, 2016.

[20] L. P. Kaelbling, M. L. Littman, and A. W. Moore,“Reinforcement learning: A survey,” J. Artif. Int. Res., pp.237–285, 1996.

[21] A. Bog, H. Plattner, and A. Zeier, “A mixed transactionprocessing and operational reporting benchmark,” InformationSystems Frontiers, vol. 13, no. 3, pp. 321–335, Jul. 2011.

[22] J. J. Levandoski, P. Larson, and R. Stoica, “Identifying hot andcold data in main-memory databases,” in ICDE, 2013.

[23] S. Das, F. Li, V. R. Narasayya, and A. C. König, “Automateddemand-driven resource scaling in relationaldatabase-as-a-service,” in SIGMOD, 2016, pp. 1923–1934.

[24] L. Breiman, J. Friedman, R. Olshen, and C. Stone,Classification and Regression Trees. Monterey, CA:Wadsworth and Brooks, 1984.

[25] D. E. Difallah, A. Pavlo, C. Curino, and P. Cudre-Mauroux,“OLTP-Bench: An extensible testbed for benchmarkingrelational databases,” VLDB, vol. 7, no. 4, pp. 277–288, 2013.

[26] S. Elnaffar, P. Martin, and R. Horman, “Automaticallyclassifying database workloads,” in CIKM, 2002, pp. 622–624.

[27] S. Chaudhuri and V. Narasayya, “AutoAdmin "what-if" indexanalysis utility,” in SIGMOD, 1998, pp. 367–378.

[28] S. Martello and P. Toth, Knapsack Problems: Algorithms andComputer Implementations. John Wiley & Sons, Inc., 1990.

[29] C. C. Holt, “Forecasting seasonals and trends by exponentiallyweighted moving averages,” International Journal ofForecasting, vol. 20, no. 1, pp. 5 – 10, 2004.

[30] P. R. Winters, “Forecasting sales by exponentially weightedmoving averages,” Management Science, vol. 6, no. 3, pp.324–342, 1960.

[31] M. Olma, M. Karpathiotakis, I. Alagiannis, M. Athanassoulis,and A. Ailamaki, “Slalom: Coasting through raw data viaadaptive partitioning and indexing,” VLDB, 2017.

[32] I. Alagiannis, S. Idreos, and A. Ailamaki, “H2O: A hands-freeadaptive store,” in SIGMOD, 2014.

[33] J. Arulraj, A. Pavlo, and P. Menon, “Bridging the archipelagobetween row-stores and column-stores for hybrid workloads,”in SIGMOD’16.

[34] M. Hammer and A. Chan, “Index selection in a self-adaptivedata base management system,” in SIGMOD, 1976, pp. 1–8.