Amazon Redshift는 2026년 6월 30일 이후에 Python UDF 사용을 더 이상 지원하지 않습니다. 해당 조치는 단계적으로 시행될 예정입니다. Python 수명 종료 및 마이그레이션 옵션에 대한 자세한 내용은 2025년 6월 30일에 게시된 [블로그 게시물](https://aws.amazon.com/blogs/big-data/amazon-redshift-python-user-defined-functions-will-reach-end-of-support-after-june-30-2026/)을 참조하세요.
# 시스템 테이블 및 뷰 참조
Amazon Redshift는 시스템 작동 방식에 대한 정보가 저장되어 있는 시스템 테이블 및 뷰가 많습니다. 이러한 시스템 테이블 및 뷰 역시 다른 데이터베이스 테이블에 대한 쿼리와 동일한 방법으로 쿼리를 실행할 수 있습니다. 이번 섹션에서는 몇 가지 시스템 테이블 쿼리 샘플을 살펴보면서 다음과 같은 주제를 가지고 설명하겠습니다.
+ 다양한 유형의 시스템 테이블 및 뷰 생성
+ 이러한 테이블에서 얻을 수 있는 정보 유형
+ Amazon Redshift 시스템 테이블을 카탈로그 테이블에 조인하는 방법
+ 점점 증가하는 시스템 테이블 로그 파일의 관리 방법
일부 시스템 테이블은 진단 목적으로 AWS 직원만 사용할 수 있습니다. 다음 섹션에서는 시스템 관리자 또는 데이터베이스 사용자가 유용한 정보를 얻기 위해 쿼리를 실행할 수 있는 시스템 테이블에 대해서 얘기하겠습니다.
**참고**
시스템 테이블은 자동 또는 수동 클러스터 백업(스냅샷)에 포함되지 않습니다. STL 시스템 뷰는 7일간의 로그 기록을 보존합니다. 따라서 로그 보존에는 별도의 고객 조치가 필요하지 않습니다. 따라서 로그 데이터를 7일 이상 보관하고 싶다면 정기적으로 다른 테이블에 복사하거나 Amazon S3으로 언로드해야 합니다.
**Topics**
+ [시스템 테이블 및 뷰의 유형](#c_types-of-system-tables-and-views)
+ [시스템 테이블 및 뷰에 있는 데이터의 가시성](#c_visibility-of-data)
+ [프로비저닝 전용 쿼리를 SYS 모니터링 뷰 쿼리로 마이그레이션](#sys_view_migration-use_cases)
+ [SYS 모니터링 뷰를 사용하여 쿼리 식별자 추적 개선](#sys_view_migration-query-id)
+ [시스템 테이블 쿼리, 프로세스 및 세션 ID](#system-table-query-process-session-ids)
+ [SVV 메타데이터 뷰](svv_views.md)
+ [SYS 모니터링 뷰](serverless_views-monitoring.md)
+ [SYS 모니터링 뷰로 마이그레이션하기 위한 시스템 뷰 매핑](sys_view_migration.md)
+ [시스템 모니터링(프로비저닝만 해당)](c_intro_system_views.md)
+ [시스템 카탈로그 테이블](c_intro_catalog_views.md)
## 시스템 테이블 및 뷰의 유형
다음과 같은 여러 유형의 시스템 테이블과 뷰가 있습니다.
+ SVV 뷰에는 임시 STV 테이블에 대한 참조와 함께 데이터베이스 객체에 대한 정보가 포함됩니다.
+ SYS 뷰는 프로비저닝된 클러스터 및 서버리스 작업 그룹의 쿼리 및 워크로드 리소스 사용량을 모니터링하는 데 사용됩니다.
+ STL 뷰는 디스크에 영구 저장되어 시스템 이력을 알려주는 로그에서 생성됩니다.
+ STV 테이블은 현재 시스템 데이터의 스냅샷을 포함하는 가상 시스템 테이블입니다. 이 두 테이블은 일시적인 인메모리 데이터를 기반으로 하기 때문에 디스크 기반 로그나 정규 테이블에 영구 저장되지는 않습니다.
+ SVCS 뷰는 동시성 확장 클러스터와 기본 클러스터 모두의 쿼리에 대한 세부 정보를 제공합니다.
+ SVL 뷰는 기본 클러스터의 쿼리에 대한 세부 정보를 제공합니다.
시스템 테이블과 뷰는 정규 테이블과 동일한 일관성 모델을 사용하지 않습니다. 특히 STV 테이블과 SVV 뷰에 대한 쿼리를 실행할 때는 이러한 문제를 알고 있어야 합니다. 예를 들어 일반 테이블 t1에 열 c1이 있다고 가정할 때 다음과 같은 쿼리는 아무런 행도 반환하지 않을 수 있습니다.
```
select * from t1
where c1 > (select max(c1) from t1)
```
하지만 시스템 테이블에 대한 다음 쿼리는 분명히 행을 반환하게 됩니다.
```
select * from stv_exec_state
where currenttime > (select max(currenttime) from stv_exec_state)
```
위 쿼리가 행을 반환할 수 있는 이유는 currenttime이 일시적이고, 쿼리에서 두 참조가 평가 시 동일한 값을 반환하지 않기 때문입니다.
반면에 다음 쿼리는 아무런 행도 반환하지 않습니다.
```
select * from stv_exec_state
where currenttime = (select max(currenttime) from stv_exec_state)
```
## 시스템 테이블 및 뷰에 있는 데이터의 가시성
**참고**
Amazon Redshift는 민감한 메타데이터의 노출을 방지하기 위해 Data Catalog 뷰에 대한 쿼리 정보를 로깅할 때 특정 시스템 테이블 열을 자동으로 마스킹합니다. 자세한 내용은 *Amazon Redshift 관리 안내서*의 [보안 로깅](https://docs.aws.amazon.com/redshift/latest/mgmt/db-auditing-secure-logging.html)을 참조하세요.
시스템 테이블 및 보기에 저장되는 데이터의 가시성은 사용자 가시성과 수퍼유저 가시성이라는 두 가지 등급이 있습니다.
수퍼유저 가시성 카테고리에 속하는 테이블의 데이터는 수퍼유저 권한이 있는 사용자만 볼 수 있습니다. 일반 사용자는 사용자 가시성 테이블의 데이터를 볼 수 있습니다. 일반 사용자에게 수퍼유저 가시성 테이블에 대한 액세스를 제공하려면 해당 테이블에 대한 SELECT 권한을 일반 사용자에게 부여합니다. 자세한 내용은 [GRANT](r_GRANT.md) 섹션을 참조하세요.
기본적으로 대부분의 사용자 가시성 테이블에서 일반 사용자는 다른 사용자가 생성한 행을 볼 수 없습니다. 일반 사용자에게 [SYSLOG ACCESS UNRESTRICTED](r_ALTER_USER.md#alter-user-syslog-access)가 부여된 경우 해당 사용자는 다른 사용자가 생성한 행을 포함하여 사용자 가시성 테이블에 있는 모든 행을 볼 수 있습니다. 자세한 내용은 [ALTER USER](r_ALTER_USER.md) 또는 [CREATE USER](r_CREATE_USER.md) 섹션을 참조하세요. SVV\_TRANSACTIONS의 모든 행은 모든 사용자에게 표시됩니다. 데이터 가시성에 대한 자세한 내용은 AWS re:Post 기술 자료 문서 [Amazon Redshift 데이터베이스의 일반 사용자에게 내 클러스터의 다른 사용자가 제공한 시스템 테이블 데이터를 볼 수 있는 권한을 허용하려면 어떻게 해야 합니까?](https://repost.aws/knowledge-center/amazon-redshift-system-tables)를 참조하세요.
메타데이터 보기의 경우 Amazon Redshift는 SYSLOG ACCESS UNRESTRICTED가 부여된 사용자에게 가시성을 허용하지 않습니다.
**참고**
사용자에게 시스템 테이블에 대한 무제한 액세스를 제공하면 다른 사용자가 생성한 데이터에 대한 가시성이 사용자에게 제공됩니다. 예를 들어, STL\_QUERY 및 STL\_QUERY\_TEXT에는 INSERT, UPDATE 및 DELETE 문의 전체 텍스트가 포함되며, 여기에는 사용자가 생성한 민감한 데이터가 포함될 수 있습니다.
수퍼유저는 모든 테이블의 모든 행을 볼 수 있습니다. 일반 사용자에게 수퍼유저 가시성 테이블에 대한 액세스를 제공하려면 해당 테이블에 대한 [GRANT](r_GRANT.md) SELECT 권한을 일반 사용자에게 부여합니다.
### 시스템 생성 쿼리 필터링
일반적으로 쿼리 관련 시스템 테이블 및 뷰(SVL\_QUERY\_SUMMARY, SVL\_QLOG 등)에는 Amazon Redshift에서 데이터베이스 상태를 모니터링하는 데 사용하는 자동 생성 문이 다수 포함되어 있습니다. 이러한 시스템 생성 쿼리도 수퍼유저에게 노출되지만 사용할 일은 거의 없습니다. 따라서 `userid` 열을 사용하는 시스템 테이블이나 시스템 뷰에서 선택할 때 이러한 쿼리를 필터링하려면 WHERE 절에 `userid > 1` 조건을 추가하면 됩니다. 예제:
```
select * from svl_query_summary where userid > 1
```
## 프로비저닝 전용 쿼리를 SYS 모니터링 뷰 쿼리로 마이그레이션
### 프로비저닝된 클러스터에서 Amazon Redshift Serverless로 마이그레이션
프로비저닝된 클러스터를 Amazon Redshift Serverless로 마이그레이션하는 경우 프로비저닝된 클러스터의 데이터만 저장하는 다음과 같은 시스템 뷰를 사용하는 쿼리가 있을 수 있습니다.
+ 모든 STL 뷰
+ 모든 STV 뷰
+ 모든 SVCS 뷰
+ 모든 SVL 뷰
+ 일부 SVV 뷰
+ Amazon Redshift Serverless에서 지원되지 않는 SVV 뷰의 전체 목록은 **Amazon Redshift 관리 안내서의 [Amazon Redshift Serverless로 쿼리 및 워크로드 모니터링](https://docs.aws.amazon.com/redshift/latest/mgmt/serverless-monitoring.html) 하단에 있는 목록을 참조하세요.
쿼리를 계속 사용하려면 SYS 모니터링 뷰에서 정의되었으며 프로비저닝 전용 뷰의 열에 해당하는 열을 사용하도록 쿼리를 다시 구성하세요. 프로비저닝 전용 뷰와 SYS 모니터링 뷰 간의 매핑 관계는 [SYS 모니터링 뷰로 마이그레이션하기 위한 시스템 뷰 매핑](sys_view_migration.md) 섹션을 참조하세요.
### 프로비저닝된 클러스터에 머물면서 쿼리 업데이트
Amazon Redshift Serverless로 마이그레이션하지 않는 경우에도 기존 쿼리를 업데이트하고 싶을 수 있습니다. SYS 모니터링 뷰는 사용 편의성과 복잡성 감소를 위해 설계되어 효과적인 모니터링 및 문제 해결을 위한 완전한 지표를 제공합니다. 여러 개의 프로비저닝 전용 뷰의 정보를 통합하는 [SYS\_QUERY\_HISTORY](SYS_QUERY_HISTORY.md) 및 [SYS\_QUERY\_DETAIL](SYS_QUERY_DETAIL.md) 등의 SYS 뷰를 사용하면 쿼리를 간소화할 수 있습니다.
## SYS 모니터링 뷰를 사용하여 쿼리 식별자 추적 개선
[SYS\_QUERY\_HISTORY](SYS_QUERY_HISTORY.md) 및 [SYS\_QUERY\_DETAIL](SYS_QUERY_DETAIL.md)과 같은 SYS 모니터링 뷰에는 사용자 쿼리에 대한 식별자가 들어 있는 query\_id 열이 포함됩니다. 마찬가지로 [STL\_QUERY](r_STL_QUERY.md) 및 [SVL\_QLOG](r_SVL_QLOG.md)와 같은 프로비저닝 전용 뷰에는 쿼리 열이 포함되며 쿼리 열에도 쿼리 식별자가 들어 있습니다. 하지만 SYS 시스템 뷰에 기록된 쿼리 식별자는 프로비저닝 전용 뷰에 기록된 쿼리 식별자와 다릅니다.
SYS 뷰의 query\_id 열 값과 프로비저닝 전용 뷰의 쿼리 열 값 간의 차이는 다음과 같습니다.
+ SYS 뷰에서 query\_id 열은 사용자가 제출한 쿼리를 원래 형식으로 기록합니다. Amazon Redshift 최적화 프로그램은 성능 향상을 위해 이러한 쿼리를 하위 쿼리로 분류할 수 있지만, 실행하는 단일 쿼리에는 [SYS\_QUERY\_HISTORY](SYS_QUERY_HISTORY.md)에 여전히 행이 하나뿐입니다. 개별 하위 쿼리는 [SYS\_QUERY\_DETAIL](SYS_QUERY_DETAIL.md)에서 확인할 수 있습니다.
+ 프로비저닝 전용 뷰에서는 쿼리 열에 하위 쿼리 수준의 쿼리가 기록됩니다. Amazon Redshift 최적화 프로그램이 원래 쿼리를 여러 하위 쿼리로 다시 작성하는 경우, 실행하는 단일 쿼리에 대해 쿼리 식별자 값이 서로 다른 여러 행이 [STL\_QUERY](r_STL_QUERY.md)에 생성됩니다.
모니터링 및 진단 쿼리를 프로비저닝 전용 뷰에서 SYS 뷰로 마이그레이션할 때는 이러한 차이를 고려하여 적절하게 쿼리를 편집하세요. Amazon Redshift의 쿼리 처리 방식에 대한 자세한 내용은 [쿼리 계획 및 실행 워크플로우](c-query-planning.md) 섹션을 참조하세요.
### 예제
Amazon Redshift가 프로비저닝 전용 뷰와 SYS 모니터링 뷰에서 어떻게 다르게 쿼리를 기록하는지 보여주는 예는 다음 샘플 쿼리를 참조하세요. 이 쿼리는 Amazon Redshift에서 실행할 때와 같이 작성된 것입니다.
```
SELECT
s_name
, COUNT(*) AS numwait
FROM
supplier,
lineitem l1,
orders,
nation
WHERE s_suppkey = l1.l_suppkey
AND o_orderkey = l1.l_orderkey
AND o_orderstatus = 'F'
AND l1.l_receiptdate > l1.l_commitdate
AND EXISTS (SELECT
*
FROM
lineitem l2
WHERE l2.l_orderkey = l1.l_orderkey
AND l2.l_suppkey <> l1.l_suppkey )
AND NOT EXISTS (SELECT
*
FROM
lineitem l3
WHERE l3.l_orderkey = l1.l_orderkey
AND l3.l_suppkey <> l1.l_suppkey
AND l3.l_receiptdate > l3.l_commitdate )
AND s_nationkey = n_nationkey
AND n_name = 'UNITED STATES'
GROUP BY
s_name
ORDER BY
numwait DESC
, s_name LIMIT 100;
```
눈에 보이지는 않지만 Amazon Redshift 쿼리 최적화 프로그램은 사용자가 제출한 위 쿼리를 5개의 하위 쿼리로 다시 작성합니다.
첫 번째 하위 쿼리는 임시 테이블을 생성하여 하위 쿼리를 구체화합니다.
```
CREATE TEMP TABLE volt_tt_606590308b512(l_orderkey
, l_suppkey
, s_name ) AS SELECT
l1.l_orderkey
, l1.l_suppkey
, public.supplier.s_name
FROM
public.lineitem AS l1,
public.nation,
public.orders,
public.supplier
WHERE l1.l_commitdate < l1.l_receiptdate
AND l1.l_orderkey = public.orders.o_orderkey
AND l1.l_suppkey = public.supplier.s_suppkey
AND public.nation.n_name = 'UNITED STATES'::CHAR(8)
AND public.nation.n_nationkey = public.supplier.s_nationkey
AND public.orders.o_orderstatus = 'F'::CHAR(1);
```
두 번째 하위 쿼리는 임시 테이블에서 통계를 수집합니다.
```
padb_fetch_sample: select count(*) from volt_tt_606590308b512;
```
세 번째 하위 쿼리는 위에서 만든 임시 테이블을 참조하여 다른 하위 쿼리를 구체화하기 위해 또 다른 임시 테이블을 만듭니다.
```
CREATE TEMP TABLE volt_tt_606590308c2ef(l_orderkey
, l_suppkey) AS (SELECT
volt_tt_606590308b512.l_orderkey
, volt_tt_606590308b512.l_suppkey
FROM
public.lineitem AS l2,
volt_tt_606590308b512
WHERE l2.l_suppkey <> volt_tt_606590308b512.l_suppkey
AND l2.l_orderkey = volt_tt_606590308b512.l_orderkey)
EXCEPT distinct (SELECT volt_tt_606590308b512.l_orderkey, volt_tt_606590308b512.l_suppkey
FROM public.lineitem AS l3, volt_tt_606590308b512
WHERE l3.l_commitdate < l3.l_receiptdate
AND l3.l_suppkey <> volt_tt_606590308b512.l_suppkey
AND l3.l_orderkey = volt_tt_606590308b512.l_orderkey);
```
네 번째 하위 쿼리도 임시 테이블의 통계를 수집합니다.
```
padb_fetch_sample: select count(*) from volt_tt_606590308c2ef
```
마지막 하위 쿼리는 위에서 만든 임시 테이블을 사용하여 출력을 생성합니다.
```
SELECT
volt_tt_606590308b512.s_name AS s_name
, COUNT(*) AS numwait
FROM
volt_tt_606590308b512,
volt_tt_606590308c2ef
WHERE volt_tt_606590308b512.l_orderkey = volt_tt_606590308c2ef.l_orderkey
AND volt_tt_606590308b512.l_suppkey = volt_tt_606590308c2ef.l_suppkey
GROUP BY
1
ORDER BY
2 DESC
, 1 ASC LIMIT 100;
```
프로비저닝 전용 시스템 뷰 STL\_QUERY에서 Amazon Redshift는 다음과 같이 하위 쿼리 수준에서 5개 행을 기록합니다.
```
SELECT userid, xid, pid, query, querytxt::varchar(100);
FROM stl_query
WHERE xid = 48237350
ORDER BY xid, starttime;
userid | xid | pid | query | querytxt
--------+----------+------------+----------+------------------------------------------------------------------------------------------------------
101 | 48237350 | 1073840810 | 12058151 | CREATE TEMP TABLE volt_tt_606590308b512(l_orderkey, l_suppkey, s_name) AS SELECT l1.l_orderkey, l1.l
101 | 48237350 | 1073840810 | 12058152 | padb_fetch_sample: select count(*) from volt_tt_606590308b512
101 | 48237350 | 1073840810 | 12058156 | CREATE TEMP TABLE volt_tt_606590308c2ef(l_orderkey, l_suppkey) AS (SELECT volt_tt_606590308b512.l_or
101 | 48237350 | 1073840810 | 12058168 | padb_fetch_sample: select count(*) from volt_tt_606590308c2ef
101 | 48237350 | 1073840810 | 12058170 | SELECT s_name , COUNT(*) AS numwait FROM supplier, lineitem l1, orders, nation WHERE s_suppkey = l1.
(5 rows)
```
SYS 모니터링 뷰 SYS\_QUERY\_HISTORY에서 Amazon Redshift는 다음과 같이 쿼리를 기록합니다.
```
SELECT user_id, transaction_id, session_id, query_id, query_text::varchar(100)
FROM sys_query_history
WHERE transaction_id = 48237350
ORDER BY start_time;
user_id | transaction_id | session_id | query_id | query_text
---------+----------------+------------+----------+------------------------------------------------------------------------------------------------------
101 | 48237350 | 1073840810 | 12058149 | SELECT s_name , COUNT(*) AS numwait FROM supplier, lineitem l1, orders, nation WHERE s_suppkey = l1.
```
SYS\_QUERY\_DETAIL에서는 SYS\_QUERY\_HISTORY\_HISTORY의 query\_id 값을 사용하여 하위 쿼리 수준의 세부 정보를 찾을 수 있습니다. child\_query\_sequence 열에는 하위 쿼리가 실행되는 순서가 표시됩니다. SYS\_QUERY\_DETAIL의 열에 대한 자세한 내용은 [SYS\_QUERY\_DETAIL](SYS_QUERY_DETAIL.md) 섹션을 참조하세요.
```
select user_id,
query_id,
child_query_sequence,
stream_id,
segment_id,
step_id,
start_time,
end_time,
duration,
blocks_read,
blocks_write,
local_read_io,
remote_read_io,
data_skewness,
time_skewness,
is_active,
spilled_block_local_disk,
spilled_block_remote_disk
from sys_query_detail
where query_id = 12058149
and step_id = -1
order by query_id,
child_query_sequence,
stream_id,
segment_id,
step_id;
user_id | query_id | child_query_sequence | stream_id | segment_id | step_id | start_time | end_time | duration | blocks_read | blocks_write | local_read_io | remote_read_io | data_skewness | time_skewness | is_active | spilled_block_local_disk | spilled_block_remote_disk
---------+----------+----------------------+-----------+------------+---------+----------------------------+----------------------------+----------+-------------+--------------+---------------+----------------+---------------+---------------+-----------+--------------------------+---------------------------
101 | 12058149 | 1 | 0 | 0 | -1 | 2023-09-27 15:40:38.512415 | 2023-09-27 15:40:38.533333 | 20918 | 0 | 0 | 0 | 0 | 0 | 44 | f | 0 | 0
101 | 12058149 | 1 | 1 | 1 | -1 | 2023-09-27 15:40:39.931437 | 2023-09-27 15:40:39.972826 | 41389 | 12 | 0 | 12 | 0 | 0 | 77 | f | 0 | 0
101 | 12058149 | 1 | 2 | 2 | -1 | 2023-09-27 15:40:40.584412 | 2023-09-27 15:40:40.613982 | 29570 | 32 | 0 | 32 | 0 | 0 | 25 | f | 0 | 0
101 | 12058149 | 1 | 2 | 3 | -1 | 2023-09-27 15:40:40.582038 | 2023-09-27 15:40:40.615758 | 33720 | 0 | 0 | 0 | 0 | 0 | 1 | f | 0 | 0
101 | 12058149 | 1 | 3 | 4 | -1 | 2023-09-27 15:40:46.668766 | 2023-09-27 15:40:46.705456 | 36690 | 24 | 0 | 15 | 0 | 0 | 17 | f | 0 | 0
101 | 12058149 | 1 | 4 | 5 | -1 | 2023-09-27 15:40:46.707209 | 2023-09-27 15:40:46.709176 | 1967 | 0 | 0 | 0 | 0 | 0 | 18 | f | 0 | 0
101 | 12058149 | 1 | 4 | 6 | -1 | 2023-09-27 15:40:46.70656 | 2023-09-27 15:40:46.71289 | 6330 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0
101 | 12058149 | 1 | 5 | 7 | -1 | 2023-09-27 15:40:46.71405 | 2023-09-27 15:40:46.714343 | 293 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0
101 | 12058149 | 2 | 0 | 0 | -1 | 2023-09-27 15:40:52.083907 | 2023-09-27 15:40:52.087854 | 3947 | 0 | 0 | 0 | 0 | 0 | 35 | f | 0 | 0
101 | 12058149 | 2 | 1 | 1 | -1 | 2023-09-27 15:40:52.089632 | 2023-09-27 15:40:52.091129 | 1497 | 0 | 0 | 0 | 0 | 0 | 11 | f | 0 | 0
101 | 12058149 | 2 | 1 | 2 | -1 | 2023-09-27 15:40:52.089008 | 2023-09-27 15:40:52.091306 | 2298 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0
101 | 12058149 | 3 | 0 | 0 | -1 | 2023-09-27 15:40:56.882013 | 2023-09-27 15:40:56.897282 | 15269 | 0 | 0 | 0 | 0 | 0 | 29 | f | 0 | 0
101 | 12058149 | 3 | 1 | 1 | -1 | 2023-09-27 15:40:59.718554 | 2023-09-27 15:40:59.722789 | 4235 | 0 | 0 | 0 | 0 | 0 | 13 | f | 0 | 0
101 | 12058149 | 3 | 2 | 2 | -1 | 2023-09-27 15:40:59.800382 | 2023-09-27 15:40:59.807388 | 7006 | 0 | 0 | 0 | 0 | 0 | 58 | f | 0 | 0
101 | 12058149 | 3 | 3 | 3 | -1 | 2023-09-27 15:41:06.488685 | 2023-09-27 15:41:06.493825 | 5140 | 0 | 0 | 0 | 0 | 0 | 56 | f | 0 | 0
101 | 12058149 | 3 | 3 | 4 | -1 | 2023-09-27 15:41:06.486206 | 2023-09-27 15:41:06.497756 | 11550 | 0 | 0 | 0 | 0 | 0 | 2 | f | 0 | 0
101 | 12058149 | 3 | 4 | 5 | -1 | 2023-09-27 15:41:06.499201 | 2023-09-27 15:41:06.500851 | 1650 | 0 | 0 | 0 | 0 | 0 | 15 | f | 0 | 0
101 | 12058149 | 3 | 4 | 6 | -1 | 2023-09-27 15:41:06.498609 | 2023-09-27 15:41:06.500949 | 2340 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0
101 | 12058149 | 3 | 5 | 7 | -1 | 2023-09-27 15:41:06.502945 | 2023-09-27 15:41:06.503282 | 337 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0
101 | 12058149 | 4 | 0 | 0 | -1 | 2023-09-27 15:41:06.62899 | 2023-09-27 15:41:06.631452 | 2462 | 0 | 0 | 0 | 0 | 0 | 22 | f | 0 | 0
101 | 12058149 | 4 | 1 | 1 | -1 | 2023-09-27 15:41:06.632313 | 2023-09-27 15:41:06.63391 | 1597 | 0 | 0 | 0 | 0 | 0 | 20 | f | 0 | 0
101 | 12058149 | 4 | 1 | 2 | -1 | 2023-09-27 15:41:06.631726 | 2023-09-27 15:41:06.633813 | 2087 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0
101 | 12058149 | 5 | 0 | 0 | -1 | 2023-09-27 15:41:12.571974 | 2023-09-27 15:41:12.584234 | 12260 | 0 | 0 | 0 | 0 | 0 | 39 | f | 0 | 0
101 | 12058149 | 5 | 0 | 1 | -1 | 2023-09-27 15:41:12.569815 | 2023-09-27 15:41:12.585391 | 15576 | 0 | 0 | 0 | 0 | 0 | 4 | f | 0 | 0
101 | 12058149 | 5 | 1 | 2 | -1 | 2023-09-27 15:41:13.758513 | 2023-09-27 15:41:13.76401 | 5497 | 0 | 0 | 0 | 0 | 0 | 39 | f | 0 | 0
101 | 12058149 | 5 | 1 | 3 | -1 | 2023-09-27 15:41:13.749 | 2023-09-27 15:41:13.772987 | 23987 | 0 | 0 | 0 | 0 | 0 | 32 | f | 0 | 0
101 | 12058149 | 5 | 2 | 4 | -1 | 2023-09-27 15:41:13.799526 | 2023-09-27 15:41:13.813506 | 13980 | 0 | 0 | 0 | 0 | 0 | 62 | f | 0 | 0
101 | 12058149 | 5 | 2 | 5 | -1 | 2023-09-27 15:41:13.798823 | 2023-09-27 15:41:13.813651 | 14828 | 0 | 0 | 0 | 0 | 0 | 0 | f | 0 | 0
(28 rows)
```
## 시스템 테이블 쿼리, 프로세스 및 세션 ID
시스템 테이블에 표시되는 쿼리, 프로세스 및 세션 ID를 분석할 때 다음 사항에 유의하세요.
+ `query_id` 및 `query`와 같은 열의 쿼리 ID 값은 시간이 지남에 따라 재사용될 수 있습니다.
+ `process_id`, `pid`, `session_id`와 같은 열의 프로세스 ID 또는 세션 ID 값은 시간이 지남에 따라 재사용될 수 있습니다.
+ `transaction_id` 및 `xid`와 같은 열의 트랜잭션 ID 값은 고유합니다.