General discussion on using the Kognitio Analytical Platform.
Single Poster
User avatar
Posts: 1
Joined: Wed Mar 28, 2018 2:54 pm

Whether any performance impact while using transformations like case statement, decode, coalesce,cast on imaged view

by leo » Wed Mar 28, 2018 3:05 pm

Hi Team,

Suppose I have a fact or dimension view imaged, Whether any performance decrease if I my select clause has transformations like case statement, decode, coalesce,cast on top of the view imaged comparing the the simple query. Also if so what will the performance impact if I simple hard code a column on top of imaged view?

Reply with quote Top
User avatar
Posts: 386
Joined: Thu May 23, 2013 4:48 pm

Re: Whether any performance impact while using transformations like case statement, decode, coalesce,cast on imaged view

by markc » Thu Mar 29, 2018 8:42 am


Unfortunately, this is going to be an "it depends" situation.

The view image will have data in RAM, and you will be able to perform simple operations on this without a discernible performance impact.

However, if you put in expressions which have a high cost to evaluate (one artificial example would be the sleepyfunc() plugin function, which sleeps for the number of seconds specified in the argument, but you could have something involving complex string processing, or an expensive external script), then as you would expect you will see a performance impact.

The best thing to do is try with a small example to see how it works with the data and expressions you have in mind. Ideally you'd do this with no concurrent access and known RAM contents before you start, as you always want to do when looking at performance, so your results aren't affected by concurrent activity, presence of transient large RAM images, etc.

Also, be aware that if your expression turns a column which is currently relatively narrow into a significantly larger string, this will impact performance as less rows will fit in buffers on the database for processing, and the row retrieval rate will be worse as the number of rows per retrieval buffer will be lower (even if the "significantly larger" string is actually a varchar which never gets near its maximum length).

I don't understand your final comment about hard-coding a column on top of an imaged view, but I suspect the answer will be similar to the above, and the best way to found out the impact for your particular use case will be to try it on a system.
Reply with quote Top

Who is online

Users browsing this forum: No registered users and 1 guest