Efficient

Differential

Timeslice

Computation

Kristian

Torp

Leo

Mark

Christian

S.

Jensen

College

of

Computing

Department

of

Mathematics

Georgia

Institute

of

Technology

and

Computer

Science

Georgia

GA

USA

Aalborg

University

Fredrik

Bajers

Vej

Aalborg

O

DENMARK

fkristian,leomarkg@cc.gatech.edu

csj@iesd.auc.dk

February

Abstract

Transaction-time

databases

record

all

previous

database

states

and

are

ever-groving

leading

to

potentially

huge

quantities

of

data

For

that

reason

efficient

query

processing

is

of

particular

importance

Due

to

the

large

size

of

transaction-time

relations

it

is

advantageous

to

utilize

cheap

writeonce

storage

media

for

storage

This

is

facilitated

by

adopting

a

log-based

storage

structure

Timeslices

i.e.

relation

states

or

snapshots

are

computed

by

traversing

the

logs

using

previously

computed

and

cached

timeslices

as

outsets

When

computing

a

new

timeslice

the

cache

will

contain

two

candidate

outsets

an

earlier

outset

and

a

later

outset

We

provide

efficient

means

of

always

picking

the

optimal

one

Specifically

we

define

and

investigate

the

use

of

a

new

data

structure

the

B

tree-like

Insertion

Tree

-LRB-

I-tree

-RRB-

for

this

purpose

The

cost

of

using

an

I-tree

for

picking

the

optimal

outset

is

similar

to

that

of

using

a

B

tree

Being

sparse

I-trees

require

little

space

overhead

and

they

are

cheap

to

maintain

as

the

underlying

relations

are

updated

I-trees

also

provide

a

basis

for

precisely

and

efficiently

estimating

the

costs

of

performing

timeslices

in

advance

This

is

useful

for

query

optimization

and

can

be

essential

in

real-time

applications

Finally

it

is

demonstrated

how

I-trees

can

be

used

in

the

computation

of

other

types

of

queries

Introduction

A

transaction-time

database

records

the

time

when

each

stored

tuple

is

current

in

the

database

and

it

thus

records

the

history

of

the

database

-LSB-

SA

-RSB-

Database

systems

supporting

transaction

time

are

useful

in

a

wide

range

of

applications

including

accounting

and

banking

where

transactions

on

accounts

are

stored

as

well

as

in

many

other

systems

where

audit

trails

are

important

-LSB-

EN

-RSB-

Applications

also

include

the

management

of

medical

records

etc.

-LSB-

DWB

-RSB-

Recent

and

continuing

advances

in

hardware

have

made

the

storage

of

ever-growing

and

potentially

huge

transaction-time

databases

a

practical

possibility

As

a

result

significant

effort

has

recently

been

devoted

to

this

topic

see

e.g.

-LSB-

RS

McK

SS

Soo

-RSB-

Research

focus

is

moving

from

conceptual

data

modeling

aspects

to

implementation-related

aspects

In

order

to

make

transaction-time

systems

practical

the

hardware

advances

must

be

combined

with

advances

in

query

processing

techniques

An

essential

operator

in

transaction-time

databases

is

the

timeslice

operator

-LSB-

Sch

-RSB-

The

timeslice

R

-LRB-

t

-RRB-

of

a

relation

R

at

time

t

now

is

the

snapshot

state

of

the

relation

R

as

of

time

t

-LSB-

AB

-RSB-

The

transaction-time

data

model

used

in

this

paper

is

the

backlog

model

-LSB-

JM

-RSB-

In

this

model

a

backlog

is

generated

and

maintained

by

the

system

for

each

relation

defined

in

the

database

schema

The

change

requests

-LRB-

i.e.

inserts

and

deletes

-RRB-

to

a

relation

are

appended

to

its

backlog

A

relation

is

derived

from

a

backlog

by

using

the

timeslice

operator

Besides

the

attributes

of

the

associated

relation

each

tuple

in

a

backlog

contains

attributes

which

make

the

implementation

of

the

timeslice

operator

possible

such

as

a

transaction

timestamp

Data

is

never

deleted

from

a

transaction-time

database

meaning

that

it

may

eventually

contain

very

large

amounts

of

data

For

transaction-time

databases

to

be

useful

queries

must

be

processed

efficiently

One

way

to

improve

efficiency

is

to

use

differential

computation

i.e.

incrementally

or

decrementally

compute

queries

from

the

cached

results

of

similar

and

previously

computed

queries

-LSB-

Rou

JM

BCL

BLT

LHMPW

CSLLM

-RSB-

The

I-tree

is

a

degenerate

sparse

B

tree

designed

for

append-only

relations

such

as

backlogs

where

data

is

inserted

in

transaction

timestamp

order

Thus

insertions

are

done

in

the

right-most

leaf

only

and

nodes

may

be

packed

completely

because

node

splitting

never

occurs

In

this

paper

we

use

an

I-tree

as

a

permanent

index

on

the

transaction-time

attribute

in

a

backlog

The

I-tree

is

updated

every

time

a

new

page

of

change

requests

is

allocated

for

the

backlog

Given

a

transaction

timestamp

the

I-tree

efficiently

locates

the

disk

pages

containing

the

change

request

-LRB-

s

-RRB-

with

that

timestamp

or

the

most

recent

earlier

timestamp

This

ability

of

the

I-tree

to

find

the

page

position

of

a

change

request

corresponding

to

a

given

timestamp

value

is

exploited

during

timeslice

computation

as

described

next

When

given

a

transaction

time

tx

at

which

to

timeslice

relation

R

the

times

tx

and

tx

of

the

nearest

earlier

and

later

timeslices

i.e.

R

-LRB-

tx

-RRB-

and

R

-LRB-

tx

-RRB-

respectively

in

the

cache

are

identified

The

I-tree

is

then

used

to

compute

page

positions

for

these

times

in

the

backlog

These

positions

can

then

be

used

to

predict

whether

it

is

going

to

be

more

efficient

to

incrementally

compute

R

-LRB-

tx

-RRB-

from

R

-LRB-

tx

-RRB-

or

decrementally

compute

R

-LRB-

tx

-RRB-

from

R

-LRB-

tx

-RRB-

The

most

efficient

outset

for

differential

computation

of

the

timeslice

operator

can

be

chosen

with

little

overhead

and

the

cost

of

computing

the

timeslice

can

be

estimated

precisely

which

is

useful

in

e.g.

real-time

applications

Also

the

I-tree

can

be

used

to

find

the

exact

number

of

change

requests

appended

to

a

backlog

in

a

given

time

interval

Such

statistics

are

useful

for

query

optimization

The

paper

is

organized

as

follows

Section

describes

the

data

structures

and

operators

in

the

backlog

model

Section

defines

the

I-tree

and

explains

why

it

is

well-suited

for

backlogs

This

section

also

compares

the

I-tree

with

related

indices

Section

shows

how

an

I-tree

index

on

a

backlog

can

be

used

to

decide

whether

incremental

or

decremental

computation

is

most

efficient

Finally

Section

shows

other

situations

where

the

I-tree

can

be

used

Section

briefly

summarizes

the

paper

and

points

to

directions

for

future

research

Implementation

Model

for

Transaction-Time

Databases

Several

data

models

support

transaction-time

for

a

recent

survey

please

see

-LSB-

Sno

-RSB-

In

this

paper

we

have

chosen

the

backlog

data

model

because

it

is

a

very

simple

first

normal

form

data

model

and

because

the

simple

query

language

has

a

formal

semantics

based

on

the

relational

algebra

-LSB-

Sno

-RSB-

Backlog

and

Cache

For

each

relation

R

defined

in

the

database

schema

the

database

system

generates

and

maintains

a

backlog

BR

A

backlog

BR

is

a

relation

which

contains

the

entire

history

of

change

requests

to

the

relation

R

The

schema

of

a

relation

R

and

its

corresponding

backlog

BR

is

shown

in

Figure

R

An

Dn

BR

Id

surr

Operation

fIns

Delg

Time

TTIME

An

Dn

Figure

The

Attributes

of

the

Relation

R

and

its

Backlog

BR

The

backlog

schema

contains

all

attributes

to

An

defined

in

the

corresponding

relation

In

addition

the

backlogs

has

three

new

attributes

Id

a

surrogate

used

as

a

tuple

identifier

for

change

requests

in

the

backlog

Operation

an

indicator

of

whether

the

change

request

is

an

insertion

or

a

deletion

-LRB-

updates

are

modeled

as

a

deletion/insertion

pairs

with

the

same

transaction

timestamp

-RRB-

and

Time

a

transaction

timestamp

It

is

assumed

that

each

change

request

has

a

unique

transaction

timestamp

-LRB-

except

updates

-RRB-

and

that

the

backlog

is

ordered

in

transaction-time

order

Figure

shows

the

effect

on

the

backlog

BR

resulting

from

a

change

request

to

the

relation

R.

Change

request

to

R

Effect

on

BR

insert

R

-LRB-

tuple

-RRB-

insert

BR

-LRB-

id

Ins

time

tuple

-RRB-

delete

R

-LRB-

k

-RRB-

insert

BR

-LRB-

id

Del

time

tuple

-LRB-

k

-RRB-

-RRB-

update

R

-LRB-

k

new

values

-RRB-

insert

BR

-LRB-

id

Del

time

tuple

-LRB-

k

-RRB-

-RRB-

insert

BR

-LRB-

id

Ins

time

k

new

values

-RRB-

Figure

Operations

on

a

Relation

and

Their

Effect

on

the

Backlog

When

an

insertion

to

R

is

requested

an

insertion

request

is

appended

to

BR

When

a

deletion

from

R

of

a

tuple

with

key

value

k

is

requested

an

insertion

request

is

appended

to

BR

The

function

tuple

-LRB-

k

-RRB-

returns

the

tuple

identified

by

k

a

primary

key

value

in

relation

R.

To

efficiently

compute

this

function

we

assume

that

a

cache

for

R

-LRB-

now

-RRB-

is

maintained

eagerly

When

an

update

of

a

tuple

with

key

value

k

is

requested

two

change

requests

are

appended

to

the

backlog

namely

a

deletion

of

the

tuple

with

the

key

value

k

and

an

insertion

of

the

tuple

with

key

value

k

and

the

new

attribute

values

The

results

of

previously

computed

timeslices

are

saved

in

view

pointer

caches

-LSB-

Rou

-RSB-

A

view

pointer

cache

is

a

stored

data

structure

containing

a

collection

of

pointers

to

change

requests

needed

to

materialize

the

result

of

the

corresponding

timeslice

The

structure

of

a

view

pointer

cache

is

-LRB-

surr

TID

surr

PID

ptr

-RRB-

where

values

of

the

attribute

are

surrogates

used

as

tuple

identifiers

in

the

view

pointer

cache

Values

of

the

attribute

TID

are

surrogates

refering

to

change

requests

in

the

backlog

Finally

values

of

the

attribute

PID

are

pointers

to

pages

in

the

backlog

where

the

change

requests

are

stored

View

pointer

caches

may

also

be

used

for

caching

results

of

more

general

queries

than

timeslices

but

this

is

beyond

the

scope

of

this

paper

Algebra

Operators

The

five

basic

relational

operators

are

retained

in

the

algebra

for

the

backlog

model

A

relation

must

be

timesliced

before

it

is

used

as

an

operand

in

an

algebra

expression

The

idea

of

timeslicing

can

be

expressed

as

follows

R

-LRB-

tx

-RRB-

denotes

R

at

time

tx

tinit

tx

now

R

denotes

R

-LRB-

now

-RRB-

The

variable

now

has

the

value

of

the

current

time

and

tinit

is

the

time

when

the

database

was

initialized

A

formal

definition

of

the

timeslice

operator

is

given

next

-LSB-

JM

-RSB-

Let

R

be

a

relation

having

attributes

An

where

Key

a

time-invariant

key

is

one

of

these

The

timeslice

R

-LRB-

tx

-RRB-

is

given

by

R

-LRB-

tx

-RRB-

fy

-LRB-

n

-RRB-

j

-LRB-

-RRB-

-LRB-

s

BR

y

-LSB-

-RSB-

s

-LSB-

-RSB-

y

-LSB-

-RSB-

s

-LSB-

-RSB-

y

-LSB-

n

-RSB-

s

-LSB-

n

-RSB-

s

-LSB-

Time

-RSB-

tx

s

-LSB-

Operation

-RSB-

Ins

-LRB-

-LRB-

u

-RRB-

-LRB-

u

BR

s

-LSB-

Key

-RSB-

u

-LSB-

Key

-RSB-

s

-LSB-

Time

-RSB-

u

-LSB-

Time

-RSB-

tx

-RRB-

-RRB-

-RRB-

g

As

can

be

seen

the

timeslice

is

computed

from

the

backlog

First

the

attributes

of

the

result

are

selected

In

the

second

line

all

insertions

that

are

before

the

timeslice

time

are

identified

The

third

line

serves

to

eliminate

all

those

insertions

that

have

been

countered

by

deletions

before

the

time

of

the

timeslice

Incremental

and

Decremental

Computation

Informally

the

idea

of

differential

computation

is

to

reuse

the

cached

results

of

previously

computed

timeslices

together

with

intermediate

change

requests

to

compute

the

results

of

new

timeslices

When

a

timeslice

query

is

issued

against

the

database

the

closest

earlier

and

later

timeslices

that

have

been

previously

computed

and

cached

are

located

Note

that

it

is

straightforward

to

locate

these

cached

timeslices

for

example

a

B

tree

on

the

times

of

the

timeslices

can

be

used

The

problem

of

query

matching

when

more

general

queries

may

be

cached

for

reuse

is

addressed

elsewhere

-LSB-

Rou

Jen

-RSB-

This

paper

addresses

the

problem

of

how

to

efficiently

determine

whether

incremental

computation

using

the

earlier

timeslice

or

decremental

computation

using

the

later

timeslice

is

most

cost-efficient

Dec.Inc.Backlogt

-LRB-

-RRB-

t

-LRB-

-RRB-

Cost

-LRB-

-RRB-

x

t

R

-LRB-

-RRB-

Cost

-LRB-

-RRB-

x

t

R

-LRB-

-RRB-

txR

-LRB-

-RRB-

ABCtime

Figure

Differential

Computation

of

the

Timeslice

Operator

The

idea

of

differential

computation

of

timeslices

is

shown

in

Figure

The

structures

R

-LRB-

tx

-RRB-

and

R

-LRB-

tx

-RRB-

are

view

pointer

caches

containing

the

results

of

previously

computed

timeslices

and

R

-LRB-

tx

-RRB-

is

the

timeslice

to

be

computed

To

incrementally

update

R

-LRB-

tx

-RRB-

to

R

-LRB-

tx

-RRB-

the

change

requests

between

A

and

B

in

Figure

must

be

traversed

Similarly

to

decrementally

downdate

R

-LRB-

tx

-RRB-

to

R

-LRB-

tx

-RRB-

the

change

requests

between

C

and

B

must

be

traversed

Algorithms

for

incremental

and

decremental

computation

of

timeslices

may

be

found

in

-LSB-

TMJ

-RSB-

I-trees

In

this

section

we

first

review

related

work

on

indices

and

explain

why

a

new

index

is

needed

We

then

describe

the

structure

of

the

I-tree

and

show

how

the

tree

is

maintained

during

insertions

to

backlogs

Related

Work

The

I-tree

is

a

degenerate

B

tree

similar

to

and

inspired

by

the

Monotonic

B

tree

-LRB-

MB

tree

-RRB-

-LSB-

EWK

-RSB-

and

the

Append-only

tree

-LRB-

AP-tree

-RRB-

-LSB-

GS

-RSB-

The

I-tree

is

specifically

designed

to

index

monotonically

increasing

values

If

a

regular

B

tree

was

used

for

this

the

nodes

would

only

be

approximately

full

-LSB-

GS

-RSB-

Several

other

indexes

may

be

used

to

index

monotonically

increasing

key

values

for

an

overview

please

see

-LSB-

T

-RSB-

Here

we

simply

describe

why

we

have

defined

a

new

index

instead

of

adopting

any

of

the

two

most

closely

related

indices

the

MB-tree

and

the

AP-tree

The

MB-tree

has

not

been

used

for

three

reasons

First

the

internal

nodes

and

the

leaf

nodes

have

different

formats

and

the

leaf

nodes

can

be

different

in

size

This

inhomogeneity

is

not

necessary

for

our

purposes

Second

internal

nodes

in

the

right-most

subtree

are

allocated

before

they

are

needed

yielding

a

space

overhead

that

we

can

avoid

Third

in

the

insertion

algorithm

extra

parameters

are

given

to

be

able

to

implement

a

Time

Index

-LSB-

EWK

-RSB-

This

extra

generality

makes

the

insertion

algorithm

more

complicated

The

AP-tree

has

not

been

used

for

three

reasons

First

all

pointers

between

nodes

in

the

AP-tree

are

double

pointers

For

our

problem

single

pointers

will

do

Second

not

all

pointers

are

used

in

the

internal

nodes

of

the

AP-tree

giving

a

slight

waste

of

space

Third

when

nodes

in

the

right-most

subtree

of

the

root

are

appended

the

chain

from

the

root

to

the

right-most

leaf

must

be

traversed

This

requires

that

these

nodes

are

stored

in

main

memory

or

read

from

secondary

storage

In

the

I-tree

designed

for

our

specific

problem

it

has

been

possible

to

eliminate

the

above

characteristics

as

we

shall

see

next

Characteristics

of

the

I-tree

An

I-tree

of

order

d

has

the

following

properties

An

example

follows

the

properties

All

nodes

-LRB-

including

the

root

internal

nodes

and

leaf

nodes

-RRB-

are

of

the

format

Pd

td

Pd

where

the

Pi

are

pointers

and

the

ti

are

key

values

A

root

node

has

i

-LRB-

non-null

-RRB-

pointers

and

i

-LRB-

non-null

-RRB-

key

values

if

it

is

not

at

leaf

i

-LRB-

d

-RRB-

The

root

has

one

pointer

if

it

is

also

a

leaf

All

internal

nodes

and

leafs

except

the

right-most

node/leaf

at

each

level

have

exactly

d

-LRB-

non-null

-RRB-

pointers

and

d

-LRB-

non-null

-RRB-

key

values

Such

nodes

are

full

Within

each

full

node

td

In

general

all

non-null

key

values

are

ordered

this

way

All

leaf

nodes

that

are

descendants

of

non-right-most

subtrees

of

the

root

are

at

the

same

level

This

portion

of

the

is

full

and

balanced

The

last

pointer

on

each

leaf

page

Pd

is

used

to

chain

leaf

nodes

together

in

search

key

order

Insertions

are

always

done

in

the

right-most

leaf

deletions

do

not

occur

and

search

is

as

in

B

trees

For

a

tree

of

height

h

and

with

a

root

that

has

n

subtrees

n

-LRB-

d

-RRB-

these

properties

hold

ffl

The

first

n

subtrees

are

full

and

balanced

and

have

height

h

ffl

The

n'th

subtree

has

at

least

height

and

at

most

h

ffl

When

the

n'th

subtree

is

full

a

new

subtree

of

height

is

created

-LRB-

explained

further

in

the

next

section

-RRB-

If

the

height

of

the

tree

is

increased

by

one

the

new

root

only

has

two

subtrees

one

that

is

filled

and

one

of

height

An

example

of

an

I-tree

is

shown

in

Figure

The

tree

shown

is

of

height

h

and

order

d

The

chain

of

pointers

and

nodes

to

the

right

is

called

the

right-most

chain

In

Figure

the

right-most

chain

consists

of

the

root

the

boldface

pointer

and

the

right-most

leaf

termed

the

current

node

The

array

is

a

dynamic

array

containing

pointers

to

all

nodes

in

the

right-most

chain

-LSB-

EWK

-RSB-

These

pointers

are

used

when

insertions

are

made

to

the

tree

In

Figure

Position

of

the

array

points

to

and

Position

points

to

The

numbers

and

refer

to

the

numbers

shown

above

the

right

corner

of

each

node

These

numbers

are

used

for

illustrating

the

dynamics

of

the

index

and

are

not

part

of

the

data

structure

Furthermore

for

each

position

in

the

array

the

level

of

the

node

is

stored

along

with

an

indication

of

whether

the

node

is

full

or

not

Figure

also

shows

that

the

right-most

subtree

of

the

root

needs

not

be

balanced

there

is

no

node

at

Level

Level

l

l

l

Figure

An

Example

of

a

I-tree

of

Height

h

and

Order

d

Insertion

into

the

I-tree

We

give

a

comprehensive

description

of

insertion

into

the

I-tree

by

means

of

three

examples

that

cover

all

possible

combinations

The

algorithm

that

formed

the

basis

for

implementing

the

I-tree

is

given

elsewhere

-LSB-

TMJ

-RSB-

Figure

shows

an

example

of

the

general

case

where

the

whole

tree

is

completely

full

and

balanced

The

key

value

must

be

inserted

A

new

leaf

is

created

and

the

new

value

inserted

A

new

root

is

created

and

the

last

key

value

in

the

old

current

node

is

inserted

The

left-most

pointer

of

the

new

root

is

set

to

point

to

the

old

root

and

the

right-most

pointer

is

set

to

point

to

the

new

leaf

The

array

is

properly

updated

Figure

shows

an

example

of

the

general

case

where

a

non-full

node

is

found

in

the

rightmost

chain

The

number

of

levels

between

the

closest

non-full

node

and

the

next

node

in

the

right-most

chain

is

one

The

key

value

must

be

inserted

A

new

leaf

is

created

and

the

value

is

inserted

The

last

key

value

in

the

old

current

node

is

inserted

in

the

non-full

node

and

a

new

right-most

pointer

in

the

node

is

set

to

point

to

the

new

leaf

The

array

is

updated

to

reflect

the

new

leaf

node

Figure

shows

an

example

of

the

general

case

where

all

nodes

in

the

right-most

subtree

of

the

root

are

full

but

the

subtree

is

not

balanced

This

case

also

covers

the

situation

when

the

root

is

full

but

the

right-most

subtree

of

the

root

not

balanced

The

key

value

is

to

be

inserted

A

new

leaf

is

created

and

the

new

key

value

is

inserted

The

last

key

value

of

the

old

current

node

is

inserted

in

a

new

node

created

between

the

right-most

node

found

to

point

directly

to

a

leaf

and

the

new

leaf

The

array

is

properly

updated

Figure

Examples

of

Appends

to

the

I-tree

Use

of

I-trees

for

Efficient

Differential

Timeslice

Computation

In

this

section

we

first

describe

how

to

find

a

page

position

in

the

backlog

using

the

I-tree

Next

we

estimate

the

size

and

the

I/O-cost

of

maintaining

the

I-tree

Finally

we

present

an

algorithm

for

choosing

between

incremental

and

decremental

computation

of

timeslices

The

basic

idea

is

to

build

an

I-tree

on

a

backlog

and

use

it

to

determine

if

it

is

more

cost

efficient

to

incrementally

update

a

cached

timeslice

R

-LRB-

tx

-RRB-

to

R

-LRB-

tx

-RRB-

tx

tx

or

decrementally

downdate

a

cached

timeslice

R

-LRB-

tx

-RRB-

to

R

-LRB-

tx

-RRB-

tx

tx

see

Figure

The

nodes

in

the

I-tree

contain

transaction

timestamps

Figure

shows

an

I-tree

on

a

backlog

BacklogPointe

r

number

pLevel

l

Level

l

l

h

Number

of

pointers

in

node

d

Figure

An

I-tree

and

a

Backlog

Finding

Page

Positions

Using

the

I-tree

To

find

the

number

of

change

requests

between

two

times

the

page

positions

in

the

backlog

of

change

requests

with

approximately

those

times

are

computed

using

the

I-tree

Then

the

desired

number

can

be

found

by

subtraction

Given

a

change

request

with

transaction

timestamp

t

its

page

position

in

the

backlog

is

found

by

using

the

I-tree

By

page

position

we

mean

the

logical

number

of

the

disk

page

of

the

backlog

on

which

the

change

request

is

stored

To

compute

this

page

position

the

following

parameters

are

needed

see

also

Figure

Name

Description

h

height

of

the

I-tree

d

order

of

the

I-tree

p

pointer

number

in

a

node

l

level

number

in

the

tree

The

page

position

is

found

by

searching

the

I-tree

with

t

as

a

parameter

For

each

level

it

is

recorded

which

pointer

number

is

followed

to

the

next

level

The

page

position

is

calculated

from

this

information

by

Formula

Page

Position

-LRB-

d

-RRB-

h

X

l

-LRB-

dh

l

pl

-RRB-

ph

-LRB-

-RRB-

Formula

may

be

explained

as

follows

The

I-tree

is

balanced

and

all

nodes

are

full

to

the

left

This

means

that

each

time

a

pointer

is

skipped

in

a

node

at

Level

l

-LRB-

d

-RRB-

dh

l

pointers

to

disk

pages

of

the

backlog

are

passed

at

the

leaf

level

The

factor

pl

is

the

pointer

number

p

followed

to

the

next

level

at

level

l.

Formula

sums

up

the

number

of

disk

pages

passed

at

each

level

from

the

root

to

the

level

just

above

leaf

level

At

the

leaf

level

one

disk

page

is

passed

each

time

the

pointer

number

p

is

increased

by

one

this

is

ph.

The

parameters

-LRB-

pl

values

-RRB-

needed

to

compute

the

page

position

are

provided

using

the

I-tree

Notice

the

first

disk-page

number

is

As

an

example

consider

finding

the

page

position

on

which

the

change

request

with

transaction

timestamp

is

stored

see

Figure

In

this

example

h

and

d

The

page

position

is

therefore

-LRB-

-RRB-

-LRB-

-RRB-

-LRB-

-RRB-

The

I/O-cost

of

computing

a

page

position

is

h

disk

accesses

the

height

of

the

tree

Maintenance

of

the

I-tree

In

this

subsection

we

estimate

the

size

of

the

I-tree

and

the

I/O-cost

for

maintaining

the

I-tree

as

a

permanent

index

on

the

backlog

I-tree

Size

versus

Backlog

Size

The

I-tree

does

not

need

to

contain

the

transaction

timestamps

of

all

the

change

requests

in

the

backlog

Only

approximately

one

transaction

timestamp

for

each

disk

page

is

needed

the

I-tree

is

a

sparse

index

Two

I-trees

of

the

same

height

are

shown

in

Figure

For

this

height

Figure

shows

a

worst-case

situation

where

the

I-tree

's

size

is

the

largest

possible

compared

to

the

size

of

the

backlog

The

rightmost

leaf

has

just

been

allocated

For

the

same

height

Figure

shows

a

best-case

situation

where

the

size

of

the

I-tree

is

the

smallest

possible

compared

to

the

size

of

the

backlog

This

I-tree

is

full

and

balanced

BA

Figure

Worst-case

-LRB-

A

-RRB-

and

Best-case

-LRB-

B

-RRB-

Situations

The

following

two

expressions

are

valid

for

height

h

and

order

d

In

the

worst-case

and

best-case

situations

the

size

of

the

I-tree

compared

with

the

size

of

the

backlog

is

described

by

Formulas

and

Worst

case

Ph

m

dm

-LRB-

d

-RRB-

dh

-LRB-

-RRB-

Best

case

Phm

dm

-LRB-

d

-RRB-

dh

-LRB-

-RRB-

Examples

of

the

worst-case

and

the

best-case

are

shown

in

the

table

below

for

height

h

and

order

d

As

can

be

seen

the

backlog

is

approximately

d

times

larger

than

the

I-tree

The

size

of

the

index

is

very

small

The

difference

for

the

worst-case

and

best-case

is

insignificant

for

realistic

trees

I-tree

Backlog

I-tree/Backlog

worst-case

best-case

I/O-Cost

of

Maintaining

the

I-tree

The

I/O

needed

to

maintain

the

backlog

itself

is

independent

of

whether

or

not

there

is

an

I-tree

index

defined

on

it

There

is

an

extra

I/O-cost

related

to

maintaining

the

I-tree

as

an

index

on

the

backlog

Here

we

describe

that

cost

We

assume

that

the

root

the

right-most

leaf

and

the

dynamic

array

of

the

I-tree

are

in

main

memory

and

that

the

costs

for

allocating

reading

and

writing

a

disk

page

are

all

the

same

There

is

an

insertion

into

the

I-tree

each

time

a

new

disk

page

is

allocated

for

the

backlog

Two

cases

should

be

distinguished

when

the

right-most

leaf

of

the

I-tree

is

not

full

and

when

that

leaf

is

full

The

latter

situation

is

rare

It

occurs

only

once

for

each

-LRB-

d

-RRB-

Nch

appends

to

the

backlog

where

d

is

the

order

of

the

I-tree

and

Nch

is

the

number

of

change

requests

which

fit

in

one

disk

page

In

the

frequent

first

case

the

I/O-cost

for

updating

the

I-tree

is

zero

In

the

second

case

the

three

possibilities

shown

in

Figure

exist

The

I/O-cost

for

these

three

possibilities

are

shown

in

the

table

below

Description

Figure

Figure

Figure

Allocate

new

leaf

node

p

p

p

Allocate

new

root/node

p

p

Read

internal

node

p

p

Write

internal

node

p

p

Write

old

root

p

Write

new

node

p

Write

current

node

p

p

p

Total

I/O-cost

In

the

worst

case

it

will

require

disk

access

to

update

the

I-tree

when

the

backlog

is

updated

It

should

be

noted

that

the

I/O-cost

is

independent

of

the

height

of

the

I-tree

The

smallest

-LRB-

i.e.

worst

case

-RRB-

average

number

of

change

request

that

can

be

appended

to

a

backlog

per

I/O

operation

needed

to

maintain

the

I-tree

index

is

given

by

-LRB-

-LRB-

d

-RRB-

Nch

-RRB-

The

table

below

shows

examples

of

how

many

change

request

can

be

appended

to

the

backlog

for

each

I-tree

I/O

operation

for

different

realistic

page

sizes

It

is

assumed

that

transaction

timestamps

occupy

bits

-LSB-

Sno

-RSB-

pointers

-LRB-

Unix

-RRB-

bits

and

change

requests

bytes

Page

size

-LRB-

bytes

-RRB-

Order

d

42 85 170 341

Nch

appends

per

I/O

27 112 451

The

number

of

appends

per

extra

disk

access

grow

with

the

square

of

the

page

size

because

both

d

and

Nch

depend

on

the

page

size

It

is

clear

that

the

I-tree

is

cheap

to

maintain

for

realistic

page

sizes

Finally

the

total

cost

of

maintaining

an

I-tree

for

a

backlog

with

j

BR

j

change

requests

is

less

than

j

BR

j

-LRB-

d

-RRB-

Nch

Choosing

between

Incremental

and

Decremental

Timeslice

Computation

We

now

present

the

algorithm

for

choosing

between

incremental

and

decremental

computation

of

timeslices

in

transaction

time

databases

The

Algorithm

To

decide

whether

to

use

incremental

or

decremental

computation

we

must

know

which

one

is

more

efficient

in

a

given

situation

In

the

algorithm

presented

below

the

time

tx

is

the

time

of

the

timeslice

to

be

computed

and

tx

and

tx

are

the

times

of

the

cached

timeslices

which

are

closest

to

tx

before

and

after

tx

respectively

Observe

that

there

will

always

exist

both

a

newer

timeslice

and

an

older

timeslice

in

the

cache

as

shown

in

Figure

The

timeslice

R

-LRB-

tinit

-RRB-

which

is

empty

is

trivially

in

the

cache

and

will

always

qualify

as

an

earlier

timeslice

Next

we

made

the

assumption

that

R

-LRB-

now

-RRB-

is

eagerly

maintained

This

timeslice

will

always

qualify

as

a

later

timeslice

The

page

positions

of

the

times

tx

tx

and

tx

are

denoted

Ptx

Ptx

and

Ptx

in

the

following

The

number

of

pages

that

must

be

read

in

order

to

do

an

incremental

computation

is

j

Ptx

Ptx

j

and

the

number

of

pages

that

must

be

read

in

order

to

do

a

decremental

computation

is

j

Ptx

Ptx

j

The

two

values

are

compared

and

the

result

reveals

the

cheapest

computation

method

The

pseudo

algorithm

for

choosing

between

incremental

and

decremental

timeslice

computation

follows

incremental

or

decremental

-LRB-

BR

tx

-RRB-

Find

R

-LRB-

tx

-RRB-

where

tx

max

-LRB-

t

tx

timeslice

at

time

t

-RRB-

Find

R

-LRB-

tx

-RRB-

where

tx

min

-LRB-

t

tx

timeslice

at

time

t

-RRB-

Ptx

page

position

of

time

tx

page

position

of

time

Ptx

page

position

of

time

tx

if

j

Ptx

j

j

Ptx

j

incremental

timeslice

-LRB-

BR

R

-LRB-

tx

-RRB-

tx

tx

-RRB-

function

call

else

decremental

timeslice

-LRB-

BR

R

-LRB-

tx

-RRB-

tx

tx

-RRB-

function

call

Two

comments

are

in

order

To

efficiently

locate

the

cached

timeslices

in

the

first

two

lines

one

may

maintain

a

B

tree

index

on

the

times

of

the

cached

timeslices

Next

it

may

be

the

case

that

no

change

request

exists

in

the

backlog

with

timestamp

tx

Thus

the

page

position

of

the

change

request

with

the

largest

timestamp

that

does

not

exceed

tx

is

computed

Comparison

with

Linear

Scan

If

no

I-tree

is

available

on

the

backlog

the

only

way

to

find

the

cost

of

computing

the

timeslice

is

to

actually

compute

the

timeslice

Therefore

to

investigate

if

the

I-tree

computation

method

is

cost

efficient

we

compare

it

to

the

cost

of

a

linear

scan

of

the

backlog

from

Ptx

up

to

To

find

the

two

timeslices

closest

to

the

desired

time

tx

a

lookup

is

done

in

the

cache

We

assume

that

the

cost

for

this

is

the

same

in

both

situations

The

cost

of

finding

the

positions

Ptx

and

Ptx

in

the

I-tree

is

h

disk

accesses

each.In

the

average-case

the

linear

scan

will

be

h

disk

accesses

better

in

approximately

of

the

cases

There

is

a

cost

for

the

estimate

but

this

cost

can

reduce

the

total

cost

of

computing

the

timeslice

in

the

other

approximately

of

the

cases

Figure

shows

the

general

case

where

the

cost

of

computing

a

timeslice

by

a

linear

scan

is

compared

to

the

cost

of

computing

a

timeslice

using

differential

computation

The

x-axis

indicates

the

position

of

Ptx

and

the

y-axis

indicates

the

number

of

disk

accesses

needed

to

compute

the

timeslice

The

solid

line

assumes

that

the

timeslice

R

-LRB-

tx

-RRB-

is

computed

incrementally

from

Ptx

while

the

dashed

curve

assumes

that

the

I-tree

is

being

used

to

determine

whether

to

do

either

incremental

or

decremental

update

from

position

Ptx

or

Ptx

respectively

Figure

indicates

that

the

I-tree

approach

looses

slightly

if

the

distances

between

the

timeslices

are

small

At

the

same

time

it

shows

that

there

can

be

significant

efficiency

gains

using

the

I-tree

Note

that

the

temporal

closeness

of

the

times

of

timeslices

is

not

a

reliable

measure

for

their

physical

closeness

i.e.

for

how

many

change

requests

that

were

entered

into

the

backlog

between

the

two

timeslice

times

To

see

the

problem

consider

an

example

where

we

assume

that

no

I-tree

is

available

and

that

the

outset

closest

in

time

to

tx

is

chosen

If

the

database

is

updated

from

a.m.

to

p.m.

only

and

we

want

to

compute

a

p.m.

timeslice

for

day

and

we

have

a

day

Number

of

Disk

Accesses

I-treeLinear

ScanPosition

of

in

the

backlog

xtPxtP

Figure

Cost

Comparison

When

Computing

Timeslices

When

Using

Linear

Scans

versus

I-trees

p.m.

cached

result

and

a

day

a.m.

cached

result

then

the

day

outset

will

be

chosen

but

the

day

outset

is

the

best

Additional

Uses

of

the

I-tree

The

I-tree

may

be

used

in

other

situations

to

make

the

database

system

more

efficient

Here

we

show

that

it

can

be

used

to

compute

an

exact

position

of

a

change

request

Whereas

the

page

position

of

a

change

request

is

the

logical

number

of

the

disk

page

on

which

the

change

request

is

stored

the

exact

position

of

a

change

request

consists

of

this

page

position

and

an

offset

The

exact

position

of

a

change

request

is

useful

when

retrieving

statistics

about

a

backlog

e.g.

which

day

were

the

most

change

requests

appended

to

the

backlog

The

exact

position

of

a

change

request

with

transaction

timestamp

tx

can

be

computed

by

finding

the

-LRB-

logical

-RRB-

page

position

where

the

change

request

resides

using

Formula

then

read

the

corresponding

disk

page

and

compute

the

change-request

position

called

pch

within

that

disk

page

When

the

number

of

change

request

in

a

full

disk

page

Nch

and

the

number

of

disk

pages

skipped

at

the

leaf

level

of

the

I-tree

Npages

are

known

the

change

request

's

exact

position

in

the

backlog

is

given

by

Npages

Nch

pch

The

cost

of

finding

the

exact

position

is

h

disk

accesses

If

a

database

administrator

wants

to

find

out

how

many

change

request

were

appended

to

a

backlog

for

the

past

day

he

could

issue

the

following

backlog-based

query

count

-LRB-

oe

-LSB-

now

day

Time

now

-RSB-

BR

-RRB-

where

count

is

an

aggregate

function

which

returns

the

cardinality

of

its

parameter

This

query

can

be

converted

to

two

point

queries

which

find

the

exact

positions

of

a

change

request

with

transaction

timestamp

t

now

day

and

t

now

The

number

of

change

requests

between

these

positions

can

be

computed

from

the

results

of

the

two

exact-position

queries

Generally

all

queries

which

count

the

total

number

of

change

requests

in

a

transaction

time

interval

can

be

converted

to

exact-position

queries

This

also

applies

to

time-varying

queries

the

moving

window

operator

-LSB-

-RSB-

and

the

operator

-LSB-

JMR

Jen

-RSB-

Details

can

be

found

in

-LSB-

TMJ

-RSB-

Summary

and

Future

Research

In

this

paper

we

have

taken

one

step

in

the

direction

of

realizing

a

global

query

optimizer

for

temporal

queries

We

have

given

a

method

which

can

predict

whether

it

is

going

to

be

more

efficient

to

incrementally

or

decrementally

compute

a

timeslice

from

a

previously

computed

and

cached

result

in

a

transaction-time

data

model

This

has

been

done

by

using

an

I-tree

as

a

permanent

index

on

transaction

timestamps

on

each

backlog

An

I-tree

is

a

sparse

B

tree-like

index

with

high

space

utilization

where

the

format

is

the

same

for

all

nodes

-LRB-

root

internal

and

leaf

-RRB-

Nodes

are

connected

by

single

pointers

which

eventually

all

will

be

used

and

the

nodes

are

not

allocated

before

they

are

needed

The

size

of

the

I-tree

in

number

of

disk

pages

has

been

estimated

and

we

have

shown

that

its

size

is

very

small

compared

to

the

size

of

the

corresponding

backlog

The

I/O-cost

for

maintaining

the

I-tree

has

been

estimated

and

found

to

be

relatively

small

for

trees

of

high

order

Finally

the

I-tree

can

be

used

in

the

actual

computation

of

a

wide

range

of

other

queries

such

as

point

queries

time-varying

queries

the

moving

window

operator

and

the

operator

Acknowledgement

Kristian

Torp

was

supported

by

The

Fulbright

Commission

Henry

og

Mary

Skovs

Fond

Grosserer

L.

F.

Foghts

Fond

Reinholdt

W.

Jorck

og

Hustrus

Fond

and

Aalborg

University

References

-LSB-

AB

-RSB-

Michel

E.

Adiba

and

Bruce

G.

Lindsay

Database

Snapshots

Proceedings

of

the

Sixth

International

Conference

on

Very

Large

Databases

pp.

-LSB-

AS

-RSB-

Ilsoo

Ahn

and

Richard

Snodgrass

Partitioned

Storage

for

Temporal

Databases

IEEE

Transaction

on

Information

Systems

Vol

No.

pp.

-LSB-

BCL

-RSB-

Jose

A.

Blakeley

Neil

Coburn

and

Per

Ake

Larson

Updating

Derived

Relations

Detecting

Irrelevant

and

Autonomously

Computable

Updates

ACM

Transactions

on

Database

Systems

Vol

No

pp

-LSB-

BLT

-RSB-

Jose

A.

Blakeley

Per

Ake

Larson

and

Frank

W.

Tompa

Efficiently

Updating

Materialized

Views

Proceedings

of

the

ACM

SIGMOD

pp.

-LSB-

BM

-RSB-

Lars

Baekgaard

and

Leo

Mark

Incremental

Evaluation

of

Time-Varying

Queries

Using

Predicate

Caches

Technical

report

Department

of

Computer

Science

University

of

Maryland

College

Park

MD

June

-LSB-

CSLLM

-RSB-

Michael

Carey

Eugene

Shekita

George

Lapis

Bruce

Lindsay

and

John

McPherson

An

Incremental

Join

Attachment

for

Starburst

Computer

Sciences

Department

University

of

Wisconsin

Madison

Technical

report

no

-LSB-

DWB

-RSB-

S.M.

Downs

M.G.

Walker

and

R.L.

Blum

Automated

Summarization

of

On-line

Medical

Records

Stanford

Memo

Stanford

University

-LSB-

EN

-RSB-

R.

Elmasri

and

S.

B.

Navathe

Fundamentals

of

Database

Systems

The

Benjamin/Cummings

Publishing

Company

Inc.

ISBN

-LSB-

EWK

-RSB-

Ramez

Elmasri

Gene

T.J.

Wuu

and

Vram

Kouramaijian

The

Time

Index

and

the

Monotonic

B

tree

In

Temporal

Databases

Theory

Design

and

Implementation

The

Benjamin/Cummings

Publishing

Company

Inc.

ISBN

pp.

-LSB-

GS

-RSB-

Himawan

Gunadhi

and

Arie

Segev

Efficient

Indexing

Methods

for

Temporal

Relations

IEEE

Transaction

On

Knowledge

and

Data

Engineering

Vol

No.

pp.

June

-LSB-

Jen

-RSB-

Christian

S.

Jensen

Towards

the

Realization

of

Transaction

Time

Database

Systems

PhD

dissertation

Technical

Report

R

Aalborg

University

March

-LSB-

JM

-RSB-

Christian

S.

Jensen

and

Leo

Mark

Queries

on

Change

in

an

Extended

Relational

Model

IEEE

Transactions

on

Knowledge

and

Data

Engineering

Vol

No

April

pp.

-LSB-

JMR

-RSB-

Christian

S.

Jensen

Leo

Mark

and

Nick

Roussopoulos

Incremental

Implementation

Model

of

Relational

Database

with

Transaction

time

IEEE

Transactions

on

Knowledge

and

Data

Engineering

Vol

No

December

-LSB-

JM

-RSB-

Christian

S.

Jensen

and

Leo

Mark

Differential

Query

Processing

in

TransactionTime

Databases

In

Temporal

Databases

Theory

Design

and

Implementation

The

Benjamin/Cummings

Publishing

Company

Inc.

ISBN

pp.

-LSB-

LHMPW

-RSB-

Bruce

Lindsay

Laura

Hass

C.

Mohan

Hamid

Pirahesh

and

Paul

Wilms

A

Snapshot

Differential

Refresh

Algorithm

Proceedings

of

the

ACM

SIGMOD

pp

-LSB-

LJ

-RSB-

Nikos

A.

Lorentzos

and

Roger

G.

Johnson

Extending

Relational

Algebra

to

Manipulate

Temporal

Data

Information

Systems

Vol

No.

pp.

289-296 1988

-LSB-

McK

-RSB-

E.

McKenzie

Bibliography

Temporal

Database

SIGMOD

Vol

No

pp.

-LSB-

-RSB-

Shamkant

B.

Navathe

and

Rafi

Ahmed

Temporal

Extensions

to

the

Relational

Model

and

SQL

In

Temporal

Databases

Theory

Design

and

Implementation

The

Benjamin/Cummings

Publishing

Company

Inc.

ISBN

pp.

-LSB-

RS

-RSB-

L.

Rowe

and

M.

Stonebraker

The

POSTGRES

Papers

UCB/ERL

University

of

California

Berkeley

CA

-LSB-

Rou

-RSB-

Nicholas

Roussopoulos

An

Incremental

Access

Method

of

ViewCache

Concept

Algorithms

and

Cost

Analysis

ACM

Transaction

on

Database

Systems

Vol

No.

pp.

September

-LSB-

Sch

-RSB-

B.

Schueler

Update

Reconsidered

In

G.

M.

Nijssen

-LRB-

ed

-RRB-

Architecture

and

Models

in

Data

Base

Management

Systems

North

Holland

Publishing

Co

-LSB-

SG

-RSB-

Arie

Segev

and

Himawan

Gunadhi

Event-Join

Optimization

in

Temporal

Relational

Databases

In

Proceedings

of

the

Fifteenth

International

Conference

on

Very

Large

Data

Bases

pp.

Amsterdam

-LSB-

SA

-RSB-

R.

Snodgrass

and

Ahn

I

A

Taxonomy

of

Time

in

Database

ACM

SIGMOD

pp.

-LSB-

Sno

-RSB-

Richard

T.

Snodgrass

Temporal

Databases

In

A.U.

Frank

I.

Campari

and

U.

Formentini

-LRB-

Eds

-RRB-

Theories

and

Methods

of

Spatio-Temporal

Reasoning

In

Geographic

Space

Springer-Verlag

Lecture

Notes

in

Computer

Science

pp.

-LSB-

Soo

-RSB-

M.D.

Soo

Bibliography

on

Temporal

Databases

SIMMOD

Vol

No

pp.

-LSB-

SS

-RSB-

R.

Stam

and

R.

Snodgrass

A

Bibliography

on

Temporal

Databases

Database

Engineering

Vol

No

pp.

-LSB-

Sto

-RSB-

Michael

Stonebaker

The

Design

of

The

Postgres

Storage

System

In

Proceedings

of

the

international

conference

on

Very

Large

Data

Bases

pp.

-LSB-

T

-RSB-

Tansel

et

al.

Temporal

Database

Theory

Design

and

Implementation

The

Benjamin/Cummings

Publishing

Company

Inc.

ISBN

-LSB-

TMJ

-RSB-

Kristian

Torp

Leo

Mark

and

Christian

S.

Jensen

Efficient

Differential

Timeslice

Computation

in

Transaction

Time

Databases

Technical

Report

Georgia

Tech

-LSB-

TMJ

-RSB-

Kristian

Torp

Leo

Mark

and

Christian

S.

Jensen

Temporal

Indexes

for

Transaction

Time

Databases

In

preparation

-LSB-

Ull

-RSB-

Jeffery

D.

Ullman

Principles

of

Database

Systems

Volume

of

Computer

Software

Engineering

Series

Computer

Science

Press

second

edition

O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O B O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O B O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O B O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B I O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O B O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O O

data models
incremental computation
indexing
snapshots
timeslice