4

Our Redshift queries are extremely slow during their first execution. Subsequent executions are much faster (e.g., 45 seconds -> 2 seconds). After investigating this problem, the query compilation appears to be the culprit. This is a known issue and is even referenced on the AWS Query Planning And Execution Workflow and Factors Affecting Query Performance pages. Amazon itself is quite tight lipped about how the query cache works (tl;dr it's a magic black box that you shouldn't worry about).

One of the things that we tried was increasing the number of nodes we had, however we didn't expect it to solve anything seeing as how query compilation is a single-node operation anyway. It did not solve anything but it was a fun diversion for a bit.

As noted, this is a known issue, however, anywhere it is discussed online, the only takeaway is either "this is just something you have to live with using Redshift" or "here's a super kludgy workaround that only works part of the time because we don't know how the query cache works".

Is there anything we can do to speed up the compilation process or otherwise deal with this? So far about the best solution that's been found is "pre-run every query you might expect to run in a given day on a schedule" which is....not great, especially given how little we know about how the query cache works.

3
  • 1
    The cold cache problem is not unique to Redshift. If you want to keep things warm you need a script to poke it once in a while. Commented Mar 29, 2018 at 16:29
  • We also face the same issues that Mike has. if anyone has any alternative solution or any solution please let us know. Commented Sep 26, 2021 at 15:24
  • @jai for what it's worth - we never found a solution for this problem. Business decided it was a deal-breaker and we switched to Snowflake Commented Sep 27, 2021 at 14:50

2 Answers 2

2

there are 3 things to consider

  1. The first run of any query causes the query to be "compiled" by redshift . this can take 2-20 seconds depending on how big it is. subsequent executions of the same query use the same compiled code, even if the where clause parameters change there is no re-compile.
  2. Data is measured as marked as "hot" when a query has been run against it, and is cached in redshift memory. you cannot (reliably) manually clear this in any way EXCEPT a restart of the cluster.
  3. Redshift will "results cache", depending on your redshift parameters (enabled by default) redshift will quickly return the same result for the exact same query, if the underlying data has not changed. if your query includes current_timestamp or similar, then this will stop if from caching. This can be turned off with SET enable_result_cache_for_session TO OFF;.

Considering your issue, you may need to run some example queries to pre compile or redesign your queries ( i guess you have some dynamic query building going on that changes the shape of the query a lot). In my experience, more nodes will increase the compile time. this process happens on the master node not the data nodes, and is made more complex by having more data nodes to consider.

Sign up to request clarification or add additional context in comments.

Comments

1

The query is probably not actually running a second time -- rather, Redshift is just returning the same result for the same query.

This can be tested by turning off the cache. Run this command:

SET enable_result_cache_for_session TO OFF; 

Then, run the query twice. It should take the same time for each execution.

The result cache is great for repeated queries. Rather than being disappointed that the first execution is 'slow', be happy that subsequent cached queries are 'fast'!

2 Comments

maybe - but 2 seconds is a little slow for a cached result query don't you think? unless perhaps that 2s includes network time. normally these are <1s
@JonScott FWIW it the "2 seconds" that I quoted is not a rigorously tested value. More an example of "several orders of magnitude difference"

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.