Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
Hello, community!
Does anyone know of any issues with manually creating indexes on tables in the data warehouse to speed query performance? I didn't want to run into problems where Compose sees an index on a table and is confused.
We're on-prem, SQL Server.
We, too, are on prem sql server. We've created a few indexes. We created a naming convention that did not conflict with the existing indexes. We created a daily SQL job that checks to see if the indexes are missing and will create them if they are. If you do a drop and recreate of the DW, like we do periodically in our test environment, the daily sql job automatically takes care of it. I can't recall if other modifications will drop all indexes, but we have this script running daily in prod and test environments just in case. I'd just be careful not to add too many so you don't impact loading.
We, too, are on prem sql server. We've created a few indexes. We created a naming convention that did not conflict with the existing indexes. We created a daily SQL job that checks to see if the indexes are missing and will create them if they are. If you do a drop and recreate of the DW, like we do periodically in our test environment, the daily sql job automatically takes care of it. I can't recall if other modifications will drop all indexes, but we have this script running daily in prod and test environments just in case. I'd just be careful not to add too many so you don't impact loading.
Thanks for the feedback!
I'd bet that the important part is choosing a naming convention that doesn't conflict with existing Compose indexes.
I suppose this is what a dev environment is for, to try things like creating indexes to make sure they don't break anything...just reading "drop and recreate" gives me chills, remembering when I had to do that in production (before I had a dev environment...long story).