Skinny Tables solution to time-out errors in Reports

How often you have came across a frustrated salesforce user who is looking towards you to solve the nagging time-out error while running his/her reports. I do not know about you but I have encountered quite many angry users who are too eager to abandon the wonderful platform that salesforce is due to timeout issues with reporting. When the database grows and an object houses around 100K records or more , the performance of salesforce report may not be optimum.  So what is the way around ? - Indexing - well its many times suggested as a workaround by Salesforce but SFDC more often than not applies indexing automatically on all the system fields ( created date , sfdc id, created by id, etc.) Creating an additional field for indexing may improve the performance a little bit but nothing phenomenal will happen. Please note indexing on any field other that auto-number and system fields can be done by creating a case with salesforce support.

Does it mean we are stuck with no solution in view ? No we can use "Skinny Tables" to provide succour to the users. Salesforce provides a feature called skinny tables which are created to hold frequently used fields and to avoid expensive joins. This will boost the performance of certain read-only operations. Salesforce keeps them in sync with their source tables when the source tables are changed.

How to get "Skinny Tables"?

If you want to leverage skinny tables , contact Salesforce Customer Support. They can enable it for you ,once enabled, skinny tables are created and used automatically where appropriate. You can’t create, access, or modify skinny tables yourself. If the report, list view, or query you’re optimizing changes—for example, to add new fields—you’ll need to contact Salesforce to update your skinny table definition.

Why use of "Skinny Tables" leads to performance enhancement? 

Salesforce in practice maintains the "Standard" and "custom" fields in separate tables which is not visible to us. Hence any query involving custom and standard fields - at the data level involves requires a join , hence the depletion in performance as database or table size increases. Skinny tables houses both custom and standard fields in same table hence leading to an enhancement in performance.

On which objects can "Skinny tables be used" ?

Skinny tables can be created on custom objects, and on Account, Contact, Opportunity, Lead, and Case objects. They can lead to enhancement of performance for reports, list views, and SOQL.

A word of caution

There’s an overhead in maintaining separate tables that hold copies of live data. Using skinny tables in an inappropriate context can lead to performance degradation instead of improvement.