- Newest
- Most votes
- Most comments
What is usually the cause of a CPU spike like what you're describing is if you are loading into a table without any compression settings. The default setting for COPY is that COMPUPDATE is ON. What happens is that Redshift will take the incoming rows, run them through every compression setting we have and return the the appropriate (smallest) compression.
To fix the issue, it's best to make sure that compression is applied to the target table of the COPY statement. Run Analyze Compression command if necessary to figure out what the compression should be and manually apply it to the DDL. For temporary tables LZO can be an excellent choice to choose because it's faster to encode on these transient tables than say ZSTD. Just to be sure also set COMPUPDATE OFF in the COPY statement.
Relevant content
- Accepted Answerasked a month ago
- asked 3 years ago
- What happens to Amazon RDS and Amazon Redshift queries that are running during a maintenance window?AWS OFFICIALUpdated 8 months ago
- AWS OFFICIALUpdated 2 years ago
- AWS OFFICIALUpdated 3 months ago
- AWS OFFICIALUpdated a year ago
Oh sorry, maybe I accidentally wrote that it is a CPU spike somwhere. The spike is in the disk size not CPU :) I am quite happy with the current compression rate as it is, but thanks for your recommendation! I will be sure to keep it in mind.