Page History

...

Though the two access methods have very different execution time, the intersection tend tends to catch with the fastest one. The overhead comparing of intersection compares to the fastest path is from 15% to 78%, while the speed up comparing . While, its speedup compares to the slowest one is about 5~10 times faster. 

Why the Tweet.creat_at access path is so fast?  

The answer is that the order of primary key (Tweet.id) is consistent with the order of Tweet.create_at. We speculates that the Tweet.id was generated by the Tweet.create_at. Thus, this secondary index is actually clustered as the primary index. As the consequence, the IO time to fetch each record is clustered. The general performance of the secondary index lookup should be as slow as the User.create_at access path.

Why the intersection is slower than the Tweet.create_at index access path?

Because we only have one disk. First, the Tweet.create_at path has to wait for the User.create_at to finish a frame to operate the intersection. These two index search is battling the disk read. Second, although the intersection itself can be finished as long as one of the input is done, we can not stop the other index scan based on our push model. Hence, the primary search is also competing the disk resource with the two index searches. 

General secondary index comparison

We know the Tweet.create_at is a primary-like key. Then we replace that access path with an RTree path which is build on the Tweet.place.bounding_box.

The experiment is slow. Stay tuned. 

Review Patch: 

https://asterix-gerrit.ics.uci.edu/#/c/577  and  https://asterix-gerrit.ics.uci.edu/#/c/578

...