Amazon Redshift will no longer support the creation of new Python UDFs starting Patch 198. Existing Python UDFs will continue to function until June 30, 2026. For more information, see the [ blog post ](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/). 

# SVL\$1QUERY\$1SUMMARY
SVL\$1QUERY\$1SUMMARY

Use the SVL\$1QUERY\$1SUMMARY view to find general information about the execution of a query.

The SVL\$1QUERY\$1SUMMARY view contains a subset of data from the SVL\$1QUERY\$1REPORT view. Note that the information in SVL\$1QUERY\$1SUMMARY is aggregated from all nodes. 

**Note**  
 The SVL\$1QUERY\$1SUMMARY view only contains information about queries performed by Amazon Redshift, not other utility and DDL commands. For a complete listing and information on all statements performed by Amazon Redshift, including DDL and utility commands, you can query the SVL\$1STATEMENTTEXT view.

SVL\$1QUERY\$1SUMMARY is visible to all users. Superusers can see all rows; regular users can see only their own data. For more information, see [Visibility of data in system tables and views](cm_chap_system-tables.md#c_visibility-of-data).

Some or all of the data in this table can also be found in the SYS monitoring view [SYS\$1QUERY\$1DETAIL](SYS_QUERY_DETAIL.md). The data in the SYS monitoring view is formatted to be easier to use and understand. We recommend that you use the SYS monitoring view for your queries.

For information about SVCS\$1QUERY\$1SUMMARY, see [SVCS\$1QUERY\$1SUMMARY](r_SVCS_QUERY_SUMMARY.md).

## Table columns
Table columns

[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/redshift/latest/dg/r_SVL_QUERY_SUMMARY.html)

## Sample queries
Sample queries

 **Viewing processing information for a query step** 

The following query shows basic processing information for each step of query 87: 

```
select query, stm, seg, step, rows, bytes
from svl_query_summary
where query = 87
order by query, seg, step;
```

This query retrieves the processing information about query 87, as shown in the following sample output: 

```
 query | stm | seg | step |  rows  |  bytes
-------+-----+-----+------+--------+---------
87     |   0 |   0 |    0 |     90 |    1890 
87     |   0 |   0 |    2 |     90 |     360 
87     |   0 |   1 |    0 |     90 |     360 
87     |   0 |   1 |    2 |     90 |    1440 
87     |   1 |   2 |    0 | 210494 | 4209880 
87     |   1 |   2 |    3 |  89500 |       0 
87     |   1 |   2 |    6 |      4 |      96 
87     |   2 |   3 |    0 |      4 |      96 
87     |   2 |   3 |    1 |      4 |      96 
87     |   2 |   4 |    0 |      4 |      96 
87     |   2 |   4 |    1 |      1 |      24 
87     |   3 |   5 |    0 |      1 |      24 
87     |   3 |   5 |    4 |      0 |       0 
(13 rows)
```

 **Determining whether query steps spilled to disk** 

The following query shows whether or not any of the steps for the query with query ID 1025 (see the [SVL\$1QLOG](r_SVL_QLOG.md) view to learn how to obtain the query ID for a query) spilled to disk or if the query ran entirely in-memory: 

```
select query, step, rows, workmem, label, is_diskbased
from svl_query_summary
where query = 1025
order by workmem desc;
```

This query returns the following sample output: 

```
query| step|  rows  |  workmem   |  label        | is_diskbased
-----+-----+--------+-----------+---------------+--------------
1025 |  0  |16000000|  141557760 |scan tbl=9     | f
1025 |  2  |16000000|  135266304 |hash tbl=142   | t
1025 |  0  |16000000|  128974848 |scan tbl=116536| f
1025 |  2  |16000000|  122683392 |dist           | f
(4 rows)
```

By scanning the values for IS\$1DISKBASED, you can see which query steps went to disk. For query 1025, the hash step ran on disk. Steps might run on disk include hash, aggr, and sort steps. To view only disk-based query steps, add **and is\$1diskbased = 't'** clause to the SQL statement in the above example.