PostgreSQL 대규모 단일 트랜잭션이 다중 트랜잭션보다 느림

Postgres에서 최근에 단일 트랜잭션에서 엄청난 양의 선택이 처리되는 경우를 보았습니다. 이것은 정말 느려서 선택을 여러 트랜잭션으로 나눠서 쿼리 시간을 획기적으로 향상 시켰습니다.PostgreSQL 대규모 단일 트랜잭션이 다중 트랜잭션보다 느림

그런 사례가 있습니까? 그것은 직관적 인 카운터와 나는 여러 트랜잭션이 바람직한 이유에 대한 기술적 인 이유가 있다면 궁금 해서요?

나의 유일한 이론은 DB가 단일 거대한 트랜잭션과 달리 여러 트랜잭션으로 ACID 특성을 유지하는 것이 더 쉽다는 것입니다.

이상합니다. 테스트 케이스를 보여줄 수 있습니까? PostgreSQL 구성이 잘못되었습니다 - 낮은 wal_buffers, checkpoint_segments, shared_buffers 또는 이와 비슷한 것 같습니다. –

다른 가능성은 직렬화 가능 레벨의 영향입니다 - 어떤 버전의 PostgreSQL을 사용합니까? –

언제나 정보가없는 성능 문제는 전혀 신경 쓸 가치가 없습니다. –

데이터베이스에 쓰는 것이 없으면 선택 항목 자체가 문제가되지 않을 것이라고 생각합니다. 순수한 select 문에서 말하는 잠금 문제는 없습니다. 이 문제는 쓰기가있을 때 발생합니다.

쓰기가있는 경우 autovacuum이 가장 오래된 쓰기 트랜잭션이 시작된 후에 작성된 항목을 정리할 수 없다는 사실을 처리해야합니다.

이와 같은 문제가 발생하는 경우 잠금 (pg_locks)을 조사하는 것이 중요하므로 쿼리와 함수를 살펴보고 이러한 잠금이 어디에서 발생하는지 확인하십시오.

SELECT은 항상 단지 SELECT이 아니며 성능 문제가 발생하는 곳을 너무 쉽게 추측 할 수 있습니다.

2013-11-08 01:47:17

답변