ALTER TABLE APPEND
기존 원본 테이블에서 데이터를 이동시켜 대상 테이블에 행을 추가합니다. 원본 테이블의 데이터가 대상 테이블에서 일치하는 열로 이동됩니다. 열 순서는 중요하지 않습니다. 대상 테이블에 데이터가 성공적으로 추가되면 원본 테이블은 비게 됩니다. ALTER TABLE APPEND는 일반적으로 데이터가 복제되지 않고 이동되므로 유사한 CREATE TABLE AS 또는 INSERT INTO 작업보다 훨씬 빠릅니다.
참고
ALTER TABLE APPEND는 원본 테이블과 대상 테이블 간에 데이터 블록을 이동합니다. 성능 개선을 위해 ALTER TABLE APPEND는 추가 작업을 수행할 때 스토리지를 압축하지 않습니다. 따라서 스토리지 사용량이 일시적으로 증가합니다. 공간을 회수하려면 VACUUM 작업을 실행합니다.
이름이 같은 열은 열 속성도 같아야 합니다. 원본 테이블 또는 대상 테이블에 다른 테이블에는 없는 열이 포함되어 있는 경우, IGNOREEXTRA 또는 FILLTARGET 파라미터를 사용하여 추가 열을 관리하는 방법을 지정하십시오.
자격 증명 열을 추가할 수 없습니다. 두 테이블 모두 자격 증명 열을 포함한 경우 이 명령은 실패합니다. 한 테이블에만 자격 증명 열이 있는 경우 FILLTARGET 또는 IGNOREEXTRA 파라미터를 포함하십시오. 자세한 내용은 ALTER TABLE APPEND 사용 시 주의 사항 단원을 참조하십시오.
GENERATED BY DEFAULT AS IDENTITY 열을 추가할 수 있습니다. GENERATED BY DEFAULT AS IDENTITY로 정의된 열을 직접 입력하는 값으로 업데이트할 수 있습니다. 자세한 내용은 ALTER TABLE APPEND 사용 시 주의 사항 단원을 참조하십시오.
대상 테이블은 영구 테이블이어야 합니다. 그러나 소스는 영구 테이블이거나 스트리밍 수집을 위해 구성된 구체화된 뷰일 수 있습니다. 두 객체 모두 동일한 배포 스타일과 배포 키(정의된 경우)를 사용해야 합니다. 객체가 정렬되어 있는 경우 두 객체 모두 동일한 정렬 스타일을 사용하고 정렬 키와 동일한 열을 정의해야 합니다.
ALTER TABLE APPEND 명령은 작업 완료 즉시 자동으로 커밋합니다. 롤백할 수 없습니다. 트랜잭션 블록(BEGIN ... END) 내에서 ALTER TABLE APPEND를 실행할 수 없습니다. 버전 관리에 대한 자세한 내용은 직렬화 가능 격리 단원을 참조하십시오.
필수 권한
ALTER TABLE APPEND 명령에 따라 다음 권한 중 하나가 필요합니다.
수퍼유저
ALTER TABLE 시스템 권한이 있는 사용자
원본 테이블에 대한 DELETE 및 SELECT 권한과 대상 테이블에 대한 INSERT 권한을 가진 사용자
구문
ALTER TABLE target_table_name APPEND FROM [ source_table_name | source_materialized_view_name ] [ IGNOREEXTRA | FILLTARGET ]
구체화된 뷰에서 추가하는 것은 구체화된 뷰가 구체화된 뷰로 스트리밍 모으기에 대해 구성된 경우에만 작동합니다.
파라미터
- target_table_name
-
행이 추가된 테이블의 이름입니다. 특정 스키마를 사용하려면 테이블의 이름만 지정하거나 schema_name.table_name 형식을 사용하십시오. 대상 테이블은 기존의 영구 테이블이어야 합니다.
- FROM source_table_name
-
추가될 행을 제공하는 테이블의 이름입니다. 특정 스키마를 사용하려면 테이블의 이름만 지정하거나 schema_name.table_name 형식을 사용하십시오. 원본 테이블은 기존의 영구 테이블이어야 합니다.
- FROM source_materialized_view_name
-
추가될 행을 제공하는 구체화된 뷰의 이름입니다. 구체화된 뷰에서 추가하는 것은 구체화된 뷰가 구체화된 뷰로 스트리밍 모으기에 대해 구성된 경우에만 작동합니다. 소스 구체화된 뷰가 이미 있어야 합니다.
- IGNOREEXTRA
-
원본 테이블이 대상 테이블에 없는 열을 포함하는 경우 추가 열에 있는 데이터를 삭제해야 함을 지정하는 키워드입니다. FILLTARGET과 함께 IGNOREEXTRA를 사용할 수 없습니다.
- FILLTARGET
-
대상 테이블이 원본 테이블에 없는 열을 포함하는 경우 해당 열을 DEFAULT 열 값으로 채워야 함을 지정하는 키워드입니다(하나가 정의되어 있거나 NULL인 경우). FILLTARGET과 함께 IGNOREEXTRA를 사용할 수 없습니다.
ALTER TABLE APPEND 사용 시 주의 사항
ALTER TABLE APPEND는 원본 테이블에서 대상 테이블로 동일한 열만 이동합니다. 열 순서는 중요하지 않습니다.
원본 테이블 또는 대상 테이블에 추가 열이 포함되어 있는 경우 다음 규칙에 따라 FILLTARGET 또는 IGNOREEXTRA를 사용합니다.
-
대상 테이블에 없는 열이 원본 테이블에 있는 경우 IGNOREEXTRA를 포함합니다. 이 명령은 원본 테이블에 있는 여분의 열은 무시합니다.
-
원본 테이블에 없는 열이 대상 테이블에 있는 경우 FILLTARGET을 포함합니다. 이 명령을 실행하면 대상 테이블의 추가 열에 기본 열 값이나 IDENTITY 값이 채워집니다(하나가 정의되어 있거나 NULL인 경우).
-
원본 테이블과 대상 테이블에 모두 추가 열이 있는 경우에는 명령이 실패합니다. FILLTARGET과 IGNOREEXTRA를 모두 사용할 수는 없습니다.
두 테이블에 모두 이름은 같지만 속성이 다른 열이 있는 경우 명령은 실패합니다. 이름이 같은 열들은 다음의 공통된 속성을 가져야 합니다.
-
데이터 유형
-
열 크기
-
압축 인코딩
-
Null이 아님
-
정렬 스타일
-
정렬 키 열
-
분산 스타일
-
분산 키 열
자격 증명 열을 추가할 수 없습니다. 원본 테이블과 대상 테이블에 모두 자격 증명 열이 있는 경우에는 명령이 실패합니다. 원본 테이블에만 자격 증명 열이 있는 경우 자격 증명 열이 무시되도록 IGNOREEXTRA 파라미터를 포함하십시오. 대상 테이블에만 자격 증명 열이 있는 경우 테이블에 대해 정의된 IDENTITY 절에 따라 자격 증명 열이 채워지도록 FILLTARGET 파라미터를 포함하십시오. 자세한 내용은 DEFAULT 단원을 참조하십시오.
ALTER TABLE APPEND 문으로 기본 자격 증명 열을 추가할 수 있습니다. 자세한 내용은 CREATE TABLE 단원을 참조하십시오.
ALTER TABLE APPEND 예
회사에서 현재의 판매 거래를 파악하기 위해 SALES_MONTHLY라는 테이블을 관리하고 있다고 해봅시다. 매달 거래 테이블에서 SALES 테이블로 데이터를 이동하려고 합니다.
이럴 때 다음과 같이 INSERT INTO 및 TRUNCATE 명령을 사용하여 이 작업을 완수할 수 있습니다.
insert into sales (select * from sales_monthly); truncate sales_monthly;
하지만 ALTER TABLE APPEND 명령을 사용하면 같은 작업을 훨씬 더 효율적으로 수행할 수 있습니다.
먼저 PG_TABLE_DEF 시스템 카탈로그 테이블을 쿼리하여 두 테이블에 모두 같은 열 속성을 가진 같은 열이 있는지 확인합니다.
select trim(tablename) as table, "column", trim(type) as type, encoding, distkey, sortkey, "notnull" from pg_table_def where tablename like 'sales%'; table | column | type | encoding | distkey | sortkey | notnull -----------+------------+-----------------------------+----------+---------+---------+-------- sales | salesid | integer | lzo | false | 0 | true sales | listid | integer | none | true | 1 | true sales | sellerid | integer | none | false | 2 | true sales | buyerid | integer | lzo | false | 0 | true sales | eventid | integer | mostly16 | false | 0 | true sales | dateid | smallint | lzo | false | 0 | true sales | qtysold | smallint | mostly8 | false | 0 | true sales | pricepaid | numeric(8,2) | delta32k | false | 0 | false sales | commission | numeric(8,2) | delta32k | false | 0 | false sales | saletime | timestamp without time zone | lzo | false | 0 | false salesmonth | salesid | integer | lzo | false | 0 | true salesmonth | listid | integer | none | true | 1 | true salesmonth | sellerid | integer | none | false | 2 | true salesmonth | buyerid | integer | lzo | false | 0 | true salesmonth | eventid | integer | mostly16 | false | 0 | true salesmonth | dateid | smallint | lzo | false | 0 | true salesmonth | qtysold | smallint | mostly8 | false | 0 | true salesmonth | pricepaid | numeric(8,2) | delta32k | false | 0 | false salesmonth | commission | numeric(8,2) | delta32k | false | 0 | false salesmonth | saletime | timestamp without time zone | lzo | false | 0 | false
다음으로, 각 테이블의 크기를 살펴봅니다.
select count(*) from sales_monthly; count ------- 2000 (1 row) select count(*) from sales; count ------- 412,214 (1 row)
이제는 다음 ALTER TABLE APPEND 명령을 실행합니다.
alter table sales append from sales_monthly;
각 테이블의 크기를 다시 살펴봅니다. 지금 SALES_MONTHLY 테이블의 행 개수는 0개인데 반해, SALES 테이블의 행 개수는 2,000개로 늘었습니다.
select count(*) from sales_monthly; count ------- 0 (1 row) select count(*) from sales; count ------- 414214 (1 row)
원본 테이블의 열 개수가 대상 테이블의 열 개수보다 많은 경우 IGNOREEXTRA 파라미터를 지정합니다. 다음 예에서는 IGNOREEXTRA 파라미터를 사용하여 SALES 테이블에 추가할 때 SALES_LISTING 테이블에 있는 추가 열을 무시합니다.
alter table sales append from sales_listing ignoreextra;
대상 테이블의 열 개수가 원본 테이블의 열 개수보다 많은 경우 FILLTARGET 파라미터를 지정합니다. 다음 예에서는 FILLTARGET 파라미터를 사용하여 SALES_MONTH 테이블에는 없는 열을 SALES_REPORT 테이블에 채웁니다.
alter table sales_report append from sales_month filltarget;
다음 예는 구체화된 뷰를 소스로 사용하여 ALTER TABLE APPEND를 사용하는 방법을 보여줍니다.
ALTER TABLE target_tbl APPEND FROM my_streaming_materialized_view;
이 예의 테이블 및 구체화된 뷰 이름은 샘플입니다. 구체화된 뷰에서 추가하는 것은 구체화된 뷰가 구체화된 뷰로 스트리밍 모으기에 대해 구성된 경우에만 작동합니다. 소스 구체화된 뷰의 모든 레코드를 구체화된 뷰와 동일한 스키마를 가진 대상 테이블로 이동하고 구체화된 뷰는 그대로 둡니다. 이는 데이터 소스가 테이블인 경우와 동일한 동작입니다.