공부, 기록

1. 채번 증가 개발팀에서 UPSERT 를 위해 주로 사용하는 INSERT ON CONFLICT DO UPDATE 구문에서 UPDATE 이후 SEQ가 증가하는 상황에 대해 확인하였습니다.시퀀스 객체는 INSERT가 발생하여 채번이 된 이후 INSERT 구문이 롤백이 되더라도 채번 자체를 취소하지 않습니다.이는 MySQL의 Auto increment 에서도 동일하게 발생하는데 INSERT ON DUPLICATE 로 UPDATE를 진행한 이후 다음 INSERT는 마지막 시퀀스에서 UPDATE가 일어난 만큼 점프한 값으로 입력이 됩니다.postgreSQL도 동일한 현상이 발생하였고 약간의 차이점은 postgreSQL의 경우 HEAP 테이블로 입력 순으로 정렬이 되는데 UPDATE가 DELETE, INSERT로..

개요운영 작업 간 테이블 컬럼 추가, 컬럼 타입 변경, 인덱스 작업이 필요하여 영향도 확인 테스트 내용테이블은 2.1G / 680 만건 db.r6g.xlarge 인스턴스 타입해당 컬럼은 인덱스 O, VARCHAR(255) 상태테스트 아래와 같이 진행컬럼 타입 변경 (varchar(255) → varchar(1000), varchar(100) → text, text → varchar(1000), varchar(1000) → varchar(255) 4개 케이스 경우 테스트)인덱스 삭제컬럼 삭제 신규 컬럼 추가온라인 인덱스 생성 테스트 스크립트 및 결과LOCK 조회 쿼리 SELECT t.relname, l.locktype, page, virtualtransaction,..

개발팀에서 IN 구문이 아닌 ANY 구문 사용을 요청을 하였습니다코드 레벨에서 IN 을 사용하면 코드가 무너지는( ? ) 원인이 있었습니다 --개발팀 코멘트IN 일때trace_id in (%s)%s 에 들어갈 조건들을 쭉 string으로 풀어해치는 로직 추가ANY 일 때trace_id = ANY($1)원래 DB 호출할 때 넘기는 parameter 그대로 사용 가능 IN과 ANY가 동일한 실행계획으로 풀리는 것으로 보이는데 성능도 동일할지 약간의 테스트를 진행해보았습니다. 테스트 테이블create table minjae_test (col1 bigserial primary key, col2 int, col3 varchar(10)); 조회 실행 계획ANY EXPLAINIndex Scan using minjae..

서비스를 모니터링 하는 중 Aurora PostgreSQL 성능 개선 도우미에 DBLoad 가 증가하고 지연 값으로는 IO:XactSync 가 잡히며 해당하는 쿼리는 COMMIT 만 찍히는 상황이 발생하여 이를 케이스 오픈을 진행해가면서 상세하게 확인하고자 하였습니다.  먼저 해당 지표는 Aurora 문서에서 다음과 같이 설명되어있습니다.IO:XactSync 이벤트는 데이터베이스가 Aurora 스토리지 하위 시스템이 일반 트랜잭션의 커밋을 승인하거나 준비된 트랜잭션(Prepared Transcation)의 커밋 또는 롤백을 확인할 때까지 대기 중일 때 발생합니다. 준비된 트랜잭션은 PostgreSQL의 2단계 커밋 지원의 일부입니다. 해당 지표가 발생하는 원인은 다음과 같습니다.Onpremise 환경의 ..