Is timesten fit for analytical application ?+ my test result

Question

quite surprised by the performance of Timesten on OLTP application, I tried to know whether timesten perform as better in OLAP (analytical application) as well.
I have the test table as below:
"ddate" date,
     "B_5"     char(2),
     "C_10"     char(2),
     "D_1000"     char(4),
     "E_2"     char(2),
     "ttl"     smallint
I have 5mil rows in the table, unique values of each attribute is B_5 = 5, C_10=10, D_1000=1000, index is created for each of the attribute except for ttl
the datastore size is over 200MB which is quite acceptable, I set the permant size at 800 MB, so now the dataset is comfortably fit in the physical memory. (I have 2G memory)
now I have a bunch of crazy query like this:
select sum(ttl) from syn where D_1000 in ('v106','v111','v113','v128','v130','v193','v250','v277','v28','v292','v3','v317','v32','v337','v34','v341','v381','v389','v415','v421','v445','v468','v487','v535','v566','v574','v575','v600','v621','v628','v63','v643','v663','v667','v671','v679','v68','v690','v691','v701','v733','v747','v754','v768','v769','v774','v779','v805','v809','v818','v824','v825','v867','v880','v881','v919','v952','v958','v984','v986','v991','v995') and C_10 in ('v1','v10','v4','v8','v9') group by ddate
The query time per query varies between 2 seconds - 12 seconds, but I never be able to see the superior experience at micro-second/query as in the benchmarking.
I using direct method on 4CPU, 2G physical memory machine, WinXP SP2, single connection, query tool is ttisql.
Is this performance reasonable with timesten?

Answer 1

Our TTree index can be used to speed up query when the condition specifies constraint on a prefix of the index. Constraint must be equality unless the constraint on the last key of this prefix which can be in-equality. So you can take advantage of this in order to reduce the number of index created. Index will take space to store and time to maintain. Note than for an update, we will update an index if and only some column of this index is changed. And when we need to update an index, we delete the old value and insert the new one so its cost will be double that of an insert or delete. If space is not an issue and/or updates is not frequent than index creation should be no problems. Otherwise consideration has to be made to balance select and update. You should also consider updating statistics so the best index can be used in case there is no index that can cover all the constraints. For instance in this case with single column index, the better index to be used is the one on d_1000 because it has more values but the optimizer wont know it unless statistics was collected. So you may have acceptable performance without additional indexes but better statistics.