PostgreSQL과 JDBC는 모든 주스를 짜냅니다. 블라디미르 시트니코프

Vladimir Sitnikov의 2016년 초 보고서 "PostgreSQL과 JDBC가 모든 주스를 짜내고 있습니다"의 녹취록을 읽어 보시기 바랍니다.

좋은 오후에요 내 이름은 블라디미르 시트니코프입니다. 저는 NetCracker에서 10년 동안 일해왔습니다. 그리고 저는 주로 생산성에 관심이 있습니다. Java와 관련된 모든 것, SQL과 관련된 모든 것이 제가 좋아하는 것입니다.

그리고 오늘은 회사에서 PostgreSQL을 데이터베이스 서버로 사용하기 시작했을 때 겪었던 일에 대해 이야기하겠습니다. 그리고 우리는 주로 Java로 작업합니다. 하지만 오늘 제가 말씀드릴 내용은 단지 자바에 관한 것이 아닙니다. 실습에서 알 수 있듯이 이는 다른 언어에서도 발생합니다.

우리는 다음과 같이 이야기할 것입니다:

• 데이터 샘플링에 대해.
• 데이터 저장에 대해.
• 그리고 성능에 대해서도요.
• 그리고 거기에 묻혀 있는 수중 갈퀴에 대해서도요.

간단한 질문부터 시작해 보겠습니다. 기본 키를 기반으로 테이블에서 하나의 행을 선택합니다.

데이터베이스는 동일한 호스트에 있습니다. 그리고 이 모든 파밍에는 20밀리초가 걸립니다.

이 20밀리초는 많은 시간입니다. 그러한 요청이 100개라면 이러한 요청을 스크롤하는 데 초당 시간을 소비하게 됩니다. 즉, 시간을 낭비하고 있는 것입니다.

우리는 이것을 좋아하지 않으며 기지가 이를 위해 우리에게 무엇을 제공하는지 살펴봅니다. 데이터베이스는 쿼리 실행을 위한 두 가지 옵션을 제공합니다.

첫 번째 옵션은 간단한 요청입니다. 무엇이 좋은가요? 우리가 그것을 받아 보낸다는 사실 그 이상은 아닙니다.

https://github.com/pgjdbc/pgjdbc/pull/478

데이터베이스에는 더 까다롭지만 더 기능적인 고급 쿼리도 있습니다. 파싱, 실행, 변수 바인딩 등의 요청을 별도로 보낼 수 있습니다.

슈퍼 확장 쿼리는 이번 보고서에서 다루지 않을 내용입니다. 아마도 우리는 데이터베이스에서 무언가를 원하고 어떤 형태로든 형성된 위시 리스트가 있습니다. 즉, 이것이 우리가 원하는 것이지만 현재와 내년에는 불가능합니다. 그래서 그냥 녹음하고 주요 인물들을 흔들면서 돌아다닐 예정이에요.

그리고 우리가 할 수 있는 것은 단순 쿼리와 확장 쿼리입니다.

각 접근 방식의 특별한 점은 무엇입니까?

일회성 실행에는 간단한 쿼리가 좋습니다. 일단 완료하고 잊어버렸습니다. 그리고 문제는 바이너리 데이터 형식을 지원하지 않는다는 것입니다. 즉, 일부 고성능 시스템에는 적합하지 않습니다.

확장 쿼리 – 구문 분석 시간을 절약할 수 있습니다. 이것이 우리가 하고 사용하기 시작한 것입니다. 이것은 정말로 우리에게 도움이 되었습니다. 구문 분석 비용만 절감되는 것은 아닙니다. 데이터 전송 비용이 절감됩니다. 바이너리 형식으로 데이터를 전송하는 것이 훨씬 더 효율적입니다.

연습을 계속해 봅시다. 이것이 일반적인 애플리케이션의 모습입니다. 자바 등이 될 수 있습니다.

성명서를 작성했습니다. 명령을 실행했습니다. 가까이에 만들어졌습니다. 여기서 실수는 어디에 있습니까? 문제는 무엇입니까? 괜찮아요. 모든 책에 이렇게 나와 있습니다. 이렇게 작성해야 합니다. 최대 성능을 원한다면 이렇게 작성하세요.

그러나 실제로는 이것이 작동하지 않는 것으로 나타났습니다. 왜? "close" 메소드가 있기 때문입니다. 그리고 이렇게 하면 데이터베이스 관점에서 볼 때 이는 마치 흡연자가 데이터베이스를 사용하는 것과 같다는 것이 밝혀졌습니다. 우리는 "PARSE EXECUTE DEALLOCATE"라고 말했습니다.

왜 이 모든 추가적인 명령문 생성 및 언로드가 필요합니까? 아무도 필요하지 않습니다. 그러나 일반적으로PreparedStatements에서 발생하는 일은 우리가 이를 닫을 때 데이터베이스의 모든 것을 닫는다는 것입니다. 이것은 우리가 원하는 것이 아닙니다.

우리는 건강한 사람들처럼 베이스와 함께 일하기를 원합니다. 우리는 성명서를 한 번 작성하고 준비한 다음 여러 번 실행합니다. 실제로 여러 번(이는 애플리케이션 전체 수명 중 한 번) 구문 분석되었습니다. 그리고 우리는 다른 REST에서 동일한 명령문 ID를 사용합니다. 이것이 우리의 목표입니다.

어떻게 이를 달성할 수 있나요?

매우 간단합니다. 문을 닫을 필요가 없습니다. 우리는 이것을 “준비하다” “실행하다”라고 씁니다.

이런 것을 시작하면 어딘가에서 뭔가가 넘칠 것이 분명합니다. 확실하지 않은 경우 시도해 볼 수 있습니다. 이 간단한 방법을 사용하는 벤치마크를 작성해 보겠습니다. 성명을 작성하십시오. 우리는 드라이버의 일부 버전에서 이 프로그램을 실행했는데, 가지고 있던 모든 메모리가 손실되면서 매우 빠르게 충돌하는 것을 발견했습니다.

그러한 오류는 쉽게 수정될 수 있다는 것이 분명합니다. 나는 그들에 대해 이야기하지 않을 것입니다. 하지만 새 버전이 훨씬 더 빠르게 작동한다고 말씀드리겠습니다. 방법은 바보같지만 그래도요.

올바르게 일하는 방법? 이를 위해 우리는 무엇을 해야 합니까?

실제로 애플리케이션은 항상 문을 닫습니다. 모든 책에는 닫으라고 나와 있습니다. 그렇지 않으면 메모리가 누출됩니다.

그리고 PostgreSQL은 쿼리를 캐시하는 방법을 모릅니다. 각 세션이 자체적으로 이 캐시를 생성해야 합니다.

그리고 우리도 구문 분석에 시간을 낭비하고 싶지 않습니다.

평소처럼 우리에게는 두 가지 옵션이 있습니다.

첫 번째 옵션은 모든 것을 PgSQL로 래핑하자는 것입니다. 거기에 캐시가 있습니다. 모든 것을 캐시합니다. 그것은 훌륭할 것입니다. 우리는 이것을 보았습니다. 요청이 100500개 있습니다. 작동하지 않습니다. 우리는 요청을 수동으로 절차로 전환하는 데 동의하지 않습니다. 아니 아니.

두 번째 옵션이 있습니다. 직접 가져와서 자르는 것입니다. 소스를 열고 절단을 시작합니다. 우리는 보고 또 보았습니다. 그렇게하는 것이 그렇게 어렵지 않다는 것이 밝혀졌습니다.

https://github.com/pgjdbc/pgjdbc/pull/319

이는 2015년 XNUMX월에 나타났습니다. 이제 더 현대적인 버전이 있습니다. 그리고 모든 것이 훌륭합니다. 매우 잘 작동하므로 애플리케이션에서 아무것도 변경하지 않습니다. 그리고 우리는 PgSQL 방향으로 생각하는 것을 중단했습니다. 즉, 이는 모든 오버헤드 비용을 거의 XNUMX으로 줄이는 데 충분했습니다.

따라서 일회성 요청마다 데이터베이스의 메모리가 낭비되는 것을 방지하기 위해 서버 준비 문은 5번째 실행 시 활성화됩니다.

당신은 물을 수 있습니다 – 숫자는 어디에 있습니까? 당신은 무엇을 얻고 있나요? 그리고 여기서는 각 요청마다 고유한 숫자가 있기 때문에 숫자를 제공하지 않겠습니다.

우리의 쿼리는 OLTP 쿼리를 구문 분석하는 데 약 20밀리초를 소비했습니다. 실행에는 0,5밀리초, 구문 분석에는 20밀리초가 걸렸습니다. 요청 – 10KiB의 텍스트, 170줄의 계획. OLTP 요청입니다. 1, 5, 10줄을 요청하며 때로는 그 이상을 요청합니다.

하지만 우리는 20밀리초를 전혀 낭비하고 싶지 않았습니다. 우리는 그것을 0으로 줄였습니다. 모든 것이 훌륭합니다.

여기서 무엇을 가져갈 수 있나요? Java가 있으면 최신 버전의 드라이버를 사용하여 기뻐하십시오.

다른 언어를 사용한다면 생각해보십시오. 이것도 필요할까요? 예를 들어 PL 8 또는 LibPQ가 있는 경우와 같이 최종 언어의 관점에서 볼 때 실행이나 구문 분석이 아닌 시간을 소비하고 있다는 것이 분명하지 않으며 이는 확인할 가치가 있습니다. 어떻게? 모든 것이 무료입니다.

그 외에는 오류와 일부 특이사항이 있습니다. 그리고 지금 당장 그들에 대해 이야기하겠습니다. 대부분은 산업 고고학, 우리가 발견한 것, 우리가 발견한 것에 관한 것입니다.

요청이 동적으로 생성되는 경우. 그런 일이 일어난다. 누군가가 문자열을 서로 붙여 SQL 쿼리를 생성합니다.

그 사람은 왜 나쁜가요? 매번 다른 문자열로 끝나기 때문에 좋지 않습니다.

그리고 이 다른 문자열의 hashCode를 다시 읽어야 합니다. 이는 실제로 CPU 작업입니다. 기존 해시에서도 긴 요청 텍스트를 찾는 것은 그리 쉽지 않습니다. 따라서 결론은 간단합니다. 요청을 생성하지 마십시오. 하나의 변수에 저장합니다. 그리고 기뻐하십시오.

다음 문제. 데이터 유형이 중요합니다. 어떤 종류의 NULL이 있는지는 중요하지 않으며 어떤 종류라도 존재하도록 하는 ORM이 있습니다. Int라면 setInt라고 말합니다. 그리고 NULL인 경우 항상 VARCHAR로 둡니다. 그리고 결국 NULL이 있다는 것이 어떤 차이를 만들까요? 데이터베이스 자체는 모든 것을 이해합니다. 그리고 이 사진은 작동하지 않습니다.

실제로 데이터베이스는 전혀 신경 쓰지 않습니다. 처음에 이것이 숫자라고 말하고 두 번째에 VARCHAR이라고 말하면 서버 준비 문을 재사용하는 것이 불가능합니다. 그리고 이 경우 우리는 선언문을 다시 작성해야 합니다.

동일한 쿼리를 실행하는 경우 열의 데이터 유형이 혼동되지 않는지 확인하세요. NULL에 주의해야 합니다. 이는 ReadyStatements를 사용하기 시작한 후에 흔히 발생하는 오류입니다.

알겠습니다. 켰습니다. 어쩌면 그들이 운전사를 데려갔을 수도 있어요. 그리고 생산성도 떨어졌습니다. 상황이 나빠졌습니다.

어떻게 이런 일이 발생하나요? 이것은 버그입니까 아니면 기능입니까? 안타깝게도 이것이 버그인지 기능인지 이해할 수 없었습니다. 그러나 이 문제를 재현하기 위한 매우 간단한 시나리오가 있습니다. 그녀는 완전히 예기치 않게 우리를 매복했습니다. 그리고 이는 말 그대로 하나의 테이블에서 샘플링하는 것으로 구성됩니다. 물론 우리는 그러한 요청을 더 많이 받았습니다. 원칙적으로 두세 개의 테이블이 포함되어 있지만 이러한 재생 시나리오가 있습니다. 데이터베이스에서 원하는 버전을 가져와서 재생해 보세요.

https://gist.github.com/vlsi/df08cbef370b2e86a5c1

요점은 두 개의 열이 있고 각 열은 인덱싱된다는 것입니다. 하나의 NULL 열에는 백만 개의 행이 있습니다. 두 번째 열에는 20줄만 포함되어 있습니다. 바인딩된 변수 없이 실행하면 모든 것이 잘 작동합니다.

바인딩된 변수로 실행을 시작하면, 즉 "?" 또는 요청에 대해 "$1"을 입력하면 결국 무엇을 받게 됩니까?

https://gist.github.com/vlsi/df08cbef370b2e86a5c1

첫 번째 실행은 예상대로입니다. 두 번째는 조금 더 빠릅니다. 뭔가가 캐시되었습니다. 셋째, 넷째, 다섯째. 그럼 쾅-그리고 그런 것. 그리고 최악의 상황은 여섯 번째 실행에서 이런 일이 발생한다는 것입니다. 실제 실행 계획이 무엇인지 이해하려면 정확히 XNUMX번의 실행을 수행해야 한다는 것을 누가 알았습니까?

누가 유죄입니까? 무슨 일이에요? 데이터베이스에는 최적화가 포함되어 있습니다. 그리고 일반적인 경우에 최적화된 것 같습니다. 따라서 어느 시점부터 그녀는 일반 계획으로 전환하지만 불행히도 다른 것으로 판명될 수 있습니다. 결과는 같을 수도 있고 다를 수도 있습니다. 그리고 이러한 동작을 유발하는 일종의 임계값이 있습니다.

이에 대해 무엇을 할 수 있나요? 물론 여기서는 아무것도 가정하기가 더 어렵습니다. 우리가 사용하는 간단한 솔루션이 있습니다. 이것은 +0, OFFSET 0입니다. 확실히 당신은 그러한 해결책을 알고 있습니다. 그냥 요청에 "+0"을 추가하면 모든 것이 정상입니다. 나중에 보여 드리겠습니다.

그리고 또 다른 옵션이 있습니다. 계획을 더 자세히 살펴보십시오. 개발자는 요청을 작성하는 것뿐만 아니라 "분석 설명"을 6번 말해야 합니다. 5이면 작동하지 않습니다.

그리고 세 번째 옵션이 있습니다. pgsql-hackers에게 편지를 쓰는 것입니다. 글을 썼는데 이것이 버그인지 기능인지는 아직 확실하지 않습니다.

https://gist.github.com/vlsi/df08cbef370b2e86a5c1

버그인지 기능인지 고민하는 동안 고치도록 하겠습니다. 요청을 받아 "+0"을 추가해 보겠습니다. 모든 것이 괜찮습니다. 두 개의 기호가 있으면 그것이 어떤 것인지, 무엇인지 생각할 필요조차 없습니다. 매우 간단합니다. 우리는 데이터베이스가 이 열에 인덱스를 사용하는 것을 금지했습니다. "+0" 열에는 인덱스가 없고 그게 전부입니다. 데이터베이스는 인덱스를 사용하지 않으므로 모든 것이 정상입니다.

이것이 6의 법칙이다. 이제 현재 버전에서는 바인딩된 변수가 있는 경우 이 작업을 6번 수행해야 합니다. 바인딩된 변수가 없으면 이것이 우리가 하는 일입니다. 그리고 결국 실패하는 것은 바로 이 요청입니다. 까다로운 일이 아닙니다.

얼마나 가능한 것 같습니까? 여기 버그, 저기 버그. 사실 버그는 어디에나 있습니다.

좀 더 자세히 살펴보겠습니다. 예를 들어 두 개의 스키마가 있습니다. 테이블 S가 있는 구성표 A와 테이블 S가 포함된 다이어그램 B. 쿼리 – 테이블에서 데이터를 선택합니다. 이 경우 우리는 무엇을 갖게 될까요? 오류가 발생합니다. 우리는 위의 모든 것을 갖게 될 것입니다. 규칙은 - 버그는 어디에나 있으며, 우리는 위의 모든 것을 갖게 될 것입니다.

이제 질문은 "왜?"입니다. 스키마가 있는 경우 테이블을 찾을 위치를 알려주는 "search_path" 변수가 있다는 문서가 있는 것 같습니다. 변수가 있을 것 같습니다.

문제는 무엇입니까? 문제는 서버에서 준비된 명령문이 누군가에 의해 search_path가 변경될 수 있다고 의심하지 않는다는 것입니다. 이 값은 데이터베이스에 대해 그대로 유지됩니다. 그리고 어떤 부분은 새로운 의미를 얻지 못할 수도 있습니다.

물론 이는 테스트하는 버전에 따라 다릅니다. 테이블이 얼마나 심각하게 다른지에 따라 다릅니다. 버전 9.1에서는 단순히 이전 쿼리를 실행합니다. 새 버전에서는 버그를 잡아서 버그가 있음을 알려줄 수 있습니다.

search_path + 서버 준비 명령문 설정 =
캐시된 계획은 결과 유형을 변경하면 안 됩니다.

어떻게 치료하나요? 간단한 조리법이 있습니다. 하지 마세요. 애플리케이션이 실행되는 동안 search_path를 변경할 필요가 없습니다. 변경하는 경우 새 연결을 만드는 것이 좋습니다.

토론(예: 열기, 토론, 추가)할 수 있습니다. 누군가가 값을 변경하면 데이터베이스가 클라이언트에게 다음과 같이 알려야 한다고 데이터베이스 개발자에게 설득할 수 있을 것입니다. “보세요. 여기에서 귀하의 값이 업데이트되었습니다. 어쩌면 문을 재설정하고 다시 만들어야 할까요?” 이제 데이터베이스는 비밀리에 작동하며 내부 어딘가에서 명령문이 변경되었음을 어떤 식으로든 보고하지 않습니다.

그리고 다시 한 번 강조하겠습니다. 이는 Java에서는 일반적이지 않습니다. 우리는 PL/pgSQL에서도 동일한 내용을 일대일로 볼 수 있습니다. 그러나 그것은 거기에서 재현될 것입니다.

좀 더 많은 데이터 선택을 시도해 보겠습니다. 우리는 선택하고 선택합니다. 백만 개의 행이 있는 테이블이 있습니다. 각 줄은 128킬로바이트입니다. 약 XNUMXGB의 데이터입니다. 그리고 Java 시스템에는 XNUMXMB의 작업 메모리가 있습니다.

우리는 모든 책에서 권장하는 대로 스트림 처리를 사용합니다. 즉, resultSet을 열고 거기에서 데이터를 조금씩 읽어옵니다. 작동할까요? 기억에서 사라질까? 좀 읽어줄래? 데이터베이스를 믿으세요. Postgres를 믿으세요. 우리는 그것을 믿지 않습니다. 우리는 OFMemory에서 떨어질까요? OutOfMemory를 경험한 사람은 누구입니까? 그 후에는 누가 고쳤나요? 누군가가 문제를 해결했습니다.

백만 개의 행이 있다면 그냥 골라서 선택할 수는 없습니다. OFFSET/LIMIT가 필요합니다. 이 옵션을 선택하는 사람은 누구입니까? 그리고 autoCommit을 사용하는 것을 선호하는 사람은 누구입니까?

평소와 같이 여기서는 가장 예상치 못한 옵션이 올바른 것으로 나타났습니다. 그리고 갑자기 autoCommit을 끄면 도움이 될 것입니다. 왜 그런 겁니까? 과학은 이것에 대해 모릅니다.

그러나 기본적으로 Postgres 데이터베이스에 연결하는 모든 클라이언트는 전체 데이터를 가져옵니다. 이와 관련하여 PgJDBC도 예외는 아니며 모든 행을 선택합니다.

FetchSize 테마에는 변형이 있습니다. 즉, 별도의 명령문 수준에서 여기에서 데이터를 10, 50으로 선택하라고 말할 수 있습니다. 그러나 이는 autoCommit을 끌 때까지 작동하지 않습니다. autoCommit을 끄면 작동이 시작됩니다.

하지만 코드를 살펴보고 어디서나 setFetchSize를 설정하는 것은 불편합니다. 따라서 전체 연결에 대한 기본값을 나타내는 설정을 만들었습니다.

그것이 우리가 말한 것입니다. 매개변수가 구성되었습니다. 그리고 우리는 무엇을 얻었습니까? 예를 들어 한 번에 10개의 행을 선택하는 등 소량을 선택하면 간접비가 매우 커집니다. 따라서 이 값은 약 XNUMX으로 설정되어야 합니다.

물론 이상적으로는 바이트 단위로 제한하는 방법을 배워야 하지만 방법은 다음과 같습니다. defaultRowFetchSize를 XNUMX 이상으로 설정하고 만족하세요.

데이터 삽입으로 넘어 갑시다. 삽입이 더 쉽고 다양한 옵션이 있습니다. 예를 들어 INSERT, VALUES입니다. 이것은 좋은 선택입니다. "INSERT SELECT"라고 말할 수 있습니다. 실제로는 똑같습니다. 성능에는 차이가 없습니다.

책에서는 Batch 문을 실행해야 한다고 말하고, 책에서는 여러 개의 괄호를 사용하여 더 복잡한 명령을 실행할 수 있다고 말합니다. 그리고 Postgres에는 놀라운 기능이 있습니다. 즉, COPY를 더 빠르게 수행할 수 있습니다.

이를 측정하면 다시 흥미로운 발견을 할 수 있습니다. 우리는 이것이 어떻게 작동하기를 원합니까? 우리는 불필요한 명령을 구문 분석하거나 실행하지 않기를 원합니다.

실제로 TCP는 이를 허용하지 않습니다. 클라이언트가 요청을 보내는 중이면 데이터베이스는 응답을 보내려고 시도할 때 요청을 읽지 않습니다. 최종 결과는 클라이언트가 데이터베이스가 요청을 읽을 때까지 기다리고, 데이터베이스는 클라이언트가 응답을 읽을 때까지 기다리는 것입니다.

따라서 클라이언트는 주기적으로 동기화 패킷을 보내야 합니다. 추가 네트워크 상호 작용, 추가 시간 낭비.

그리고 더 많이 추가할수록 상황은 더욱 악화됩니다. 드라이버는 매우 비관적이며 라인 크기 등에 따라 약 200라인마다 한 번씩 추가합니다.

https://github.com/pgjdbc/pgjdbc/pull/380

한 줄만 수정하면 모든 작업 속도가 10배 빨라집니다. 그런 일이 일어난다. 왜? 늘 그렇듯이 이와 같은 상수는 이미 어딘가에서 사용되었습니다. 그리고 값 "128"은 일괄 처리를 사용하지 않는다는 의미입니다.

Java 마이크로벤치마크 하네스

정식 버전에는 포함되지 않은 것이 다행입니다. 출시가 시작되기 전에 발견되었습니다. 내가 제공하는 모든 의미는 현대 버전을 기반으로 합니다.

한번 입어보자. InsertBatch를 간단하게 측정합니다. InsertBatch를 여러 번 측정합니다. 즉, 동일한 것이지만 값이 많습니다. 까다로운 움직임. 모든 사람이 이것을 할 수 있는 것은 아니지만 매우 간단한 동작이고 COPY보다 훨씬 쉽습니다.

COPY를 할 수 있습니다.

그리고 구조물에서도 이 작업을 수행할 수 있습니다. 사용자 기본 유형을 선언하고 배열과 INSERT를 테이블에 직접 전달합니다.

pgjdbc/ubenchmsrk/InsertBatch.java 링크를 열면 이 코드는 GitHub에 있습니다. 구체적으로 어떤 요청이 생성되었는지 확인할 수 있습니다. 그것은 중요하지 않습니다.

우리는 출시했습니다. 그리고 우리가 가장 먼저 깨달은 것은 배치를 사용하지 않는 것은 불가능하다는 것입니다. 모든 일괄 처리 옵션은 XNUMX입니다. 즉, 일회성 실행에 비해 실행 시간이 사실상 XNUMX입니다.

데이터를 삽입합니다. 아주 간단한 표입니다. 세 개의 열입니다. 여기서 우리는 무엇을 볼 수 있습니까? 우리는 이 세 가지 옵션이 모두 대략 비슷하다는 것을 알 수 있습니다. 물론 COPY가 더 좋습니다.

이때 조각을 삽입합니다. VALUES 값 10개, VALUES 값 1개, VALUES 값 2개를 말하거나 그 중 4개를 쉼표로 구분하여 표시했습니다. 이제 수평이 되었습니다. 128, XNUMX, XNUMX, XNUMX. 파란색으로 그려진 Batch Insert를 보면 기분이 훨씬 좋아지는 것을 알 수 있습니다. 즉, 한 번에 하나씩 삽입하거나 한 번에 XNUMX개를 삽입해도 VALUES에 조금 더 넣었기 때문에 두 배로 좋아지는 것입니다. EXECUTE 작업이 적습니다.

소규모 볼륨에서 COPY를 사용하는 것은 매우 유망합니다. 처음 두 개는 그리지도 않았어요. 그들은 천국에 갑니다. 즉, COPY를 위한 녹색 숫자입니다.

COPY는 데이터 행이 XNUMX개 이상일 때 사용해야 합니다. 이 연결을 여는 오버헤드가 큽니다. 그리고 솔직히 말해서 저는 이 방향으로 파고들지 않았습니다. Batch를 최적화했지만 COPY는 최적화하지 않았습니다.

다음에는 무엇을 해야 할까요? 우리는 그것을 시도했습니다. 우리는 여러 의미를 결합한 구조나 영리한 바트를 사용해야 한다는 것을 이해합니다.

오늘 보고서에서 무엇을 빼내야 할까요?

• ReadyStatement는 우리의 전부입니다. 이는 생산성에 많은 이점을 제공합니다. 연고에 큰 덩어리가 생깁니다.
• 그리고 EXPLAIN ANALYZE를 6번 해야 합니다.
• 그리고 문제가 있는 쿼리의 나머지 비율을 수정하려면 OFFSET 0과 +0과 같은 트릭을 희석해야 합니다.

출처 : habr.com