Is it possible to use cached results of an already-run query in another query?

Question

The results of queries are cached until the next refresh: 1, 2.

Is it possible to refer to those cached results in other queries?

I imagine if there is, it might look something like this:

SELECT * FROM [data.stackexchange.com/<site-name>/revision/<query-id>/<revision-id>/#<table-number>?<query-parameters>]

Where <table-number> is for if the batch has multiple result sets.

---

The reason I thought of this question is because it seems like it could be used as a technique to compose more complicated queries where various parts take a long time to execute.

I'm pretty new to SQL and TSQL. I know a bit about the WITH statement, and nested queries, and today I learned there's an EXECUTE thing, but I'm guessing those will all be part of the same execution timeout timer.

This could very well be an XY problem (with me just needing to learn how to write queries that execute better), but still, I ask.

Answer 1

No, this is not possible.

The Query Result gets stored in a table named CachedResult and that table is part of the Data.StackExchange database. For regular SEDE users there is no way to access that database because the user principal that is running our queries doesn't have any access to that database.

This query would show that:

use [Data.StackExchange]
go

select * 
from sys.tables;

which leads to

Line 1: The server principal "STACKEXCHANGE\svc_sede" is not able to access the database "Data.StackExchange" under the current security context.

Compared with

use [StackExchange.Meta]
go

select * 
from sys.tables;

which returns the tables in the schema for the Stackexchange.Meta database that are available for us to query.

It is also not trivial to expose the rows from that table by any means. That table holds the CachedResults for all sites and is primarily accessed by its QueryHash which isn't publicly shared, based on my preliminary investigation. Before a cached result is returned the eviction rules are applied, resulting in a null result from the cache and the actual results being deleted from the CachedResults table. Even if SQL Server had a convenient way to fetch data from that table, the results would be wildly unstable.

If you have a query that exceeds the allotted runtime of 2 minutes you have to look for other means to tune your query. Use the Execution Plan and look for table scans is low hanging fruit. Once those options are tried and failed you can either search or ask on Meta where one of the resident SEDE users is happy to have a look at a query or you can turn for specific questions to our sister site Database Administrators and/or Code Review, where I both asked and answered questions.