공부, 기록

PostgreSQL의 LOCK에 대한 개념을 알고 싶어서 작성. wait와 lock을 확인하기 위한 방법성능 개선 도우미를 확인한다 (Aurora)pg_stat_activity : 프로세스 수준의 다양한 정보를 제공하는 시스템 뷰https://www.postgresql.org/docs/16/monitoring-stats.html#MONITORING-PG-STAT-ACTIVITY-VIEWpg_locks : 데이터베이스 서버 내 현재 활동 중인 프로세스가 소유 및 대기 중인 Lock 정보를 제공하는 시스템 뷰https://www.postgresql.org/docs/16/view-pg-locks.htmlpg_locks와 pg_stat_activity를 통해 현재 Lock을 소유한 프로세스(Holder)와 대기..

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