This repository has been archived by the owner on Oct 20, 2022. It is now read-only.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Creates an inline table valued function to get the zone id from the links table.
Uses that inline function in UtcToLocal and LocalToUTC
Schema binds functions
I was seeing some decent performance improvement from this. Processing 70,000 dates went from about 25 seconds to about 17. I don't like this metric, I would rather pay attention to actual reads/writes/cpu, but that data is hard to get for non-inline functions as the query optimizer black boxes them.
Turns out that writing an inline version of UtcToLocal actually makes things worse. Probably a result of the query optimizer choking on the complexity from the cross applies that end up being used. SQL Server is fun that way.
IMO, it would make sense to just keep duplicate data in the intervals table for all the linked time zones, instead of running a query to get the canonical timezone from the link, and then looking up that time zone. This allows basic inner joins to retrieve data, instead of functions, and that's always going to perform better. Should more than make up for the extra rows in the table (especially since the table is never written). As an added bonus, you can create some indexed views you otherwise wouldn't be able to create.
I also wonder what would happen if the clustered index on the zones table were just the IANA zone name (lose the surrogate key). Yes, it's wide, but that puts the cluster on the primary lookup column, which is good.
Let me know if you want me to try any of this stuff.