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/). 

# STL\$1ALERT\$1EVENT\$1LOG
<a name="r_STL_ALERT_EVENT_LOG"></a>

Records an alert when the query optimizer identifies conditions that might indicate performance issues. Use the STL\$1ALERT\$1EVENT\$1LOG view to identify opportunities to improve query performance.

A query consists of multiple segments, and each segment consists of one or more steps. For more information, see [Query processing](c-query-processing.md). 

STL\$1ALERT\$1EVENT\$1LOG 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).

**Note**  
STL\$1ALERT\$1EVENT\$1LOG only contains queries run on main provisioned clusters. It doesn't contain queries run on concurrency scaling clusters or on serverless namespaces. To access explain plans for queries run on both main clusters, concurrency scaling clusters, and serverless namespaces, we recommend that you use 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.

## Table columns
<a name="r_STL_ALERT_EVENT_LOG-column2"></a>

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

## Usage notes
<a name="r_STL_ALERT_EVENT_LOG-usage-notes"></a>

You can use the STL\$1ALERT\$1EVENT\$1LOG to identify potential issues in your queries, then follow the practices in [Query performance tuning](c-optimizing-query-performance.md) to optimize your database design and rewrite your queries. STL\$1ALERT\$1EVENT\$1LOG records the following alerts: 
+ **Missing statistics** 

  Statistics are missing. Run ANALYZE following data loads or significant updates and use STATUPDATE with COPY operations. For more information, see [Amazon Redshift best practices for designing queries](c_designing-queries-best-practices.md).
+ **Nested loop **

  A nested loop is usually a Cartesian product. Evaluate your query to ensure that all participating tables are joined efficiently.
+ **Very selective filter**

  The ratio of rows returned to rows scanned is less than 0.05. Rows scanned is the value of `rows_pre_user_filter` and rows returned is the value of rows in the [STL\$1SCAN](r_STL_SCAN.md) system view. Indicates that the query is scanning an unusually large number of rows to determine the result set. This can be caused by missing or incorrect sort keys. For more information, see [Sort keys](t_Sorting_data.md). 
+ **Excessive ghost rows **

  A scan skipped a relatively large number of rows that are marked as deleted but not vacuumed, or rows that have been inserted but not committed. For more information, see [Vacuuming tables](t_Reclaiming_storage_space202.md). 
+ **Large distribution **

  More than 1,000,000 rows were redistributed for hash join or aggregation. For more information, see [Data distribution for query optimization](t_Distributing_data.md). 
+ **Large broadcast **

  More than 1,000,000 rows were broadcast for hash join. For more information, see [Data distribution for query optimization](t_Distributing_data.md). 
+ **Serial execution **

   A DS\$1DIST\$1ALL\$1INNER redistribution style was indicated in the query plan, which forces serial execution because the entire inner table was redistributed to a single node. For more information, see [Data distribution for query optimization](t_Distributing_data.md).

## Sample queries
<a name="r_STL_ALERT_EVENT_LOG-sample-queries"></a>

The following query shows alert events for four queries. 

```
SELECT query, substring(event,0,25) as event, 
substring(solution,0,25) as solution, 
trim(event_time) as event_time from stl_alert_event_log order by query;

 query |             event             |          solution            |     event_time      
-------+-------------------------------+------------------------------+---------------------
  6567 | Missing query planner statist | Run the ANALYZE command      | 2014-01-03 18:20:58
  7450 | Scanned a large number of del | Run the VACUUM command to rec| 2014-01-03 21:19:31
  8406 | Nested Loop Join in the query | Review the join predicates to| 2014-01-04 00:34:22
 29512 | Very selective query filter:r | Review the choice of sort key| 2014-01-06 22:00:00

(4 rows)
```