페이지네이션 성능 가이드라인

오프셋 및 키셋 페이지네이션 모두에 적용되는 페이지네이션(정렬) 성능 개선 방법을 설명합니다.

다음 문서는 페이지네이션(정렬) 성능을 개선하기 위한 몇 가지 아이디어를 제공합니다. 이 내용은 오프셋 및 키셋 페이지네이션 모두에 적용됩니다. 타이브레이커 칼럼 # 칼럼을 정렬할 때는 고유한 칼럼만으로 정렬하는 것이 좋습니다. 다음 예제를 살펴보세요: id created_at 1 2021-01-04 14:13:43 2 2021-01-05 19:03:12 3 2021-01-05 19:03:12 created_at 으로 정렬하면, 결과는 레코드가 디스크에 저장된 위치에 따라 달라질 수 있습니다. 타이브레이커 칼럼은 데이터가 API와 같이 자동화된 프로세스에서 소비되는 잘 정의된 인터페이스를 통해 노출될 때 사용하는 것이 좋습니다. 타이브레이커 칼럼 없이는 행의 순서가 변경될 수 있으며(데이터 재임포트), 이로 인해 디버깅하기 어려운 다음과 같은 문제가 발생할 수 있습니다: 변경 사항을 감지하기 위해 행을 비교하는 통합이 중단됩니다. E-tag 캐시 값이 변경되어 전체 재다운로드가 필요하게 됩니다. SELECT issues.* FROM issues ORDER BY created_at; ORDER BY 에 두 번째 칼럼을 추가하여 이를 수정할 수 있습니다: SELECT issues.* FROM issues ORDER BY created_at, id; 이 변경으로 순서가 고유해져 "안정적인" 정렬이 가능해집니다. 쿼리를 효율적으로 만들려면 두 칼럼 모두를 포함하는 인덱스 (created_at, id) 가 필요합니다. 칼럼 순서는 ORDER BY 절의 칼럼 순서와 일치해야 합니다 . 증분 정렬 # PostgreSQL 13에서 증분 정렬(incremental sorting)이 추가되었으며, 이를 통해 인덱스를 추가하거나 교체하지 않고도 ORDER BY 절에 타이브레이커 칼럼을 도입할 수 있습니다. 또한 증분 정렬을 사용하면 새 인덱스가 빌드되기 전에(비동기 인덱스) 새로운 키셋 페이지네이션 데이터베이스 쿼리를 도입할 수 있습니다. 증분 정렬은 기본적으로 활성화되어 있습니다. 다음 데이터베이스 쿼리를 살펴보세요: SELECT * FROM merge_requests WHERE author_id = 1 ORDER BY created_at ASC LIMIT 20 이 쿼리는 다음 인덱스를 사용하여 20개의 행을 읽습니다: "index_merge_requests_on_author_id_and_created_at" btree (author_id, created_at) created_at 칼럼이 고유하지 않으므로 이 쿼리를 키셋 페이지네이션과 함께 사용하는 것은 불가능합니다. 타이브레이커 칼럼을 추가해 보겠습니다: SELECT * FROM merge_requests WHERE author_id = 1 ORDER BY created_at ASC, id ASC LIMIT 20 실행 계획: Limit (cost=1.99..30.97 rows=20 width=910) (actual time=1.217..1.220 rows=20 loops=1) Buffers: share