I have a large table that I need to re-sort periodically. I am partly basing this on a suggestion I was given to stay away from using cluster keys since I am inserting data ordered differently (by time) from how I need it clustered (by ID), and that can cause re-clustering to get a little out of control.
Since I am writing to the table on a hourly I am wary of causing problems with these two processes conflicting: If I CTAS to a newly sorted temp table and then swap the table name it seems like I am opening the door to have a write on the source table not make it to the temp table.
I figure I can trigger a flag when I am re-sorting that causes the ETL to pause writing, but that seems a bit hacky and maybe fragile.
I was considering leveraging locking and transactions, but this doesn’t seem to be the right use case for this since I don’t think I’d be locking the table I am copying from while I write to a new table. Any advice on how to approach this?
Advertisement
Answer
There are some reasons to avoid the automatic reclustering, but they’re basically all the same reasons why you shouldn’t set up a job to re-cluster frequently. You’re making the database do all the same work, but without the built in management of it.
If your table is big enough that you are seeing performance issues with the clustering by time, and you know that the ID column is the main way that this table is filtered (in JOINs and WHERE clauses) then this is probably a good candidate for automatic clustering.
So I would recommend at least testing out a cluster key on the ID and then monitoring/comparing performance.
To give a brief answer to the question about resorting without conflicts as written: I might recommend using a time column to re-sort records older than a given time (probably in a separate table). While it’s sorting, you may get some new records. But you will be able to use that time column to marry up those new records with the, now sorted, older records.