created at 2023-03-16
INDEX
- 인덱싱된 user_id, 그러나 Sequential…
- 그렇다면 어떻게 사용하도록 할 수 있을까요?
- 영구적인 인덱싱 활용 쿼리설정(feat. AWS RDS)
- 파라미터 그룹 생성
- enable_seqscan 파라미터 수정
- RDS 인스턴스의 파라미터 그룹 변경
- 결과 확인
이전까지 select 문를 효과적으로 사용하고 있다고 생각했는데 사실 indexing을 전혀 활용하고 있지 않았었습니다.
Sequential 하게 처음부터 끝까지 확인하고 있더라구요 ㅜㅜ. 예를 들어서 저는 400만건의 row를 가지는 테이블 내 user_id가 ‘A’인 유저를 쿼리하는 메소드가 있어요. 그리고 이 A 유저가 row 맨 끝에 있다고 했을 때, 400만건 전체를 linear 하게 읽어서 처리한다는 뜻이죠! 매우매우매우 cost 가 많이 들어가는 방법입니다.
왜 사용하고 있지 않았을까요? 분명 index 정보를 보면, btree 알고리즘으로 유니크한 user_id에 대해 인덱스가 만들어졌는데 말이죠!
참고로
Row Exclusive Lock은 인덱스에 먼저 걸고 그 다음 테이블에 Lock을 겁니다.
1. 인덱싱된 user_id, 그러나 Sequential…
위의 그림에서 확인할 수 있듯이, Postgresql 이 user_table_pkey 라는 인덱스를 자동으로 만들어놓죠?(물론 PK 를 설정해서 만들어 놓는 것입니다) 그렇지만, 인덱싱된 user_id와 그렇지 않은 user_pw 전부 Seq Scan 하고 있는 것을 확인할 수 있어요.
이런 이유는 기본적으로 postgres는 전부 리니어하게 읽도록 설정되기 때문입니다.
2. 그렇다면 어떻게 사용하도록 할 수 있을까요?
일시적인 방법으로는 set enable_seqscan = off 쿼리로 동일 트랜젝션 내 쿼리가 인덱싱을 활용할 수 있도록 설정할 수 있어요!
3. 영구적인 인덱싱 쿼리설정(feat. AWS RDS)
영구적인 방법으로는 postgres.conf 파일의 enable_seqscan을 off로 수정하는거에요!
저는 AWS RDS를 사용하기에 해당 파라미터를 간단하게 수정할 수 있어요.
3-1. 파라미터 그룹 생성
기본설정그룹에서는 해당 파라미터를 수정할 수 없습니다. 따라서 우리는 새롭게 파라미터 그룹을 생성할거에요. 
3-2. 파라미터 수정
3-3. RDS 인스턴스의 파라미터 그룹 변경
3-4. 결과 확인
굳이 set enable_seqscan = off 를 매 트랜젝션 앞에 두지 않고도 다음과 같이 인덱싱을 활용하는 것을 볼 수 있어요. 
아참. enable_seqscan 을 off 로 설정한다고 하더라도 여전히 시퀀셜로 스캐닝 할 수 있답니다!(indexing 되지 않는 컬럼 조회 시)
3-5. max_connection 또한 변경 가능
파라미터 그룹에서 DB의 connection 개수도 직접 변경할 수 있어요. 저같은 경우에는 83개로 설정되어 있습니다. 