PostgreSQL에서 buffer cache에 데이터를 로드하는 방법

우리는 모두 데이터가 캐시에서 접근하는 것이 디스크에서 접근하는 속도보다 훨씬 빠르다는 것을 알고 있다. 그러면 우리는 어떻게 pg에서 지정한 데이터를 캐시에 불러오는가. 이것은 Oracle의 in-memory와 약간 유사하다.
물론 데이터를 메모리에 불러오는 것이 반드시 좋은 것은 아니다. 디스크에 비해 메모리가 항상 제한되어 있기 때문에 우리는 특수한 상황에서 필요한 데이터를 메모리에 불러와 접근 속도를 높일 뿐이다.
우리는 pg_를 사용할 수 있다prewarm 플러그인은 지정한 테이블을 OS 버퍼나 pgshared 버퍼에 불러옵니다.

설치:

bill=# create extension pg_prewarm ;
CREATE EXTENSION

성능 테스트:

테스트 테이블 t1,t2 구축, 각각 1000W 테스트 데이터 삽입

bill=# create table t1(id int,info text);
CREATE TABLE
bill=# create table t2(id int,info text);
CREATE TABLE
bill=# insert into t1 select generate_series(1,10000000),md5(random()::text);
INSERT 0 10000000
bill=# insert into t2 select generate_series(1,10000000),md5(random()::text);
INSERT 0 10000000

테스트 전에 shared_ 비우기buffer, 아래 sql로 shared_ 보기 가능buffer 사용량:
설치 pg_buffercache 플러그인:

bill=# create extension pg_buffercache;
CREATE EXTENSION

질의shared_buffer 사용량:

SELECT
    c.relname,
    count(*) AS buffers
FROM pg_buffercache b
INNER JOIN pg_class c
   ON b.relfilenode = pg_relation_filenode(c.oid)
    AND b.reldatabase IN (0, (SELECT oid FROM pg_database
WHERE datname = current_database()))
GROUP BY c.relname
ORDER BY 2 DESC;
                 relname                 | buffers
-----------------------------------------+---------
 pg_attribute                            |      36
 pg_proc                                 |      27
 pg_class                                |      15
 pg_operator                             |      14
 pg_depend_reference_index               |      13
 pg_depend                               |      11
 pg_attribute_relid_attnum_index         |      10
 pg_proc_proname_args_nsp_index          |       9
......

t1과 t2 테이블이 shared_에 없음을 볼 수 있습니다buffer에서 t2 테이블을shared_에 수동으로 불러옵니다.버퍼 중.

bill=# SELECT pg_prewarm('t2');
 pg_prewarm
------------
      83334
(1 row)

성능 테스트:

전체 스캐너 t2표의 성능이 많이 향상되는 것을 볼 수 있다.

bill=# explain analyze select * from t1;
                                                    QUERY PLAN
------------------------------------------------------------------------------------------------------------------
 Seq Scan on t1  (cost=0.00..183334.80 rows=10000080 width=37) (actual time=0.060..772.902 rows=10000000 loops=1)
 Planning Time: 0.294 ms
 Execution Time: 1044.922 ms
(3 rows)

Time: 1045.722 ms (00:01.046)

bill=# explain analyze select * from t2;
                                                    QUERY PLAN
------------------------------------------------------------------------------------------------------------------
 Seq Scan on t2  (cost=0.00..183334.80 rows=10000080 width=37) (actual time=0.012..519.691 rows=10000000 loops=1)
 Planning Time: 0.280 ms
 Execution Time: 790.607 ms
(3 rows)

Time: 791.314 ms

pg_prewarm 추가 설명:

다음은 주로 pg_prewarm 함수:
이 편지함의 작성 문구는 다음과 같습니다.

CREATE FUNCTION pg_prewarm(regclass,
mode text default buffer,
fork text default main,
first_block int8 default null,
last_block int8 default null)
RETURNS int8
AS MODULE_PATHNAME, pg_prewarm
LANGUAGE C

매개변수는 다음과 같습니다.

regclass:prewarm의 표명을 만들어야 합니다

모드:prewarm 모드.prefetch는 oscache에 비동기적으로 추출됨을 나타냅니다.read는 동기화 프리페치를 표시합니다.buffer는 PG를 동시에 읽어들이는 shared buffer를 나타냅니다

fork:relation fork의 유형.일반적으로main을 사용하고, 다른 유형은visibilitymap과 fsm가 있습니다

first_block & last_block: 시작과 끝 블록 번호.표의first_block=0,last_block은 pg_class의relpages 필드를 획득합니다

RETURNS int8: 함수 반환 pg_prewarm 처리된 블록 수 (정형)

아마도 누군가가 생각할 것이다. 내가 직접 시계select* 전체 시계를 한 번 조회하면 데이터를 캐시에 불러올 수 있잖아. 왜 pg_를 사용해야 하는지.프리웜은요?왜냐하면 크기가 shared를 초과했기 때문이다_buffer/4의 시계를 전체 시계 스캐닝할 때 pg는 일반적으로 모든shared_를 사용하지 않습니다버퍼가 아니라 아주 적은 부분만 사용하는shared_buffer.따라서 캐시에 큰 테이블을 불러오는 것은 조회 하나로 직접 할 수 없습니다. pg_prewarm은 이 수요를 충족시킬 수 있다.

참조 링크:

https://www.postgresql.org/docs/13/pgprewarm.html
https://www.postgresql.org/docs/13/pgbuffercache.html
이 글은 PostgreSQL에서 버퍼캐치에 데이터를 불러오는 글에 대해 소개합니다. 더 많은 관련 PostgreSQL 데이터가 버퍼캐치에 불러오는 내용은 저희 이전의 글을 검색하거나 아래의 관련 글을 계속 보십시오. 앞으로 많은 응원 부탁드립니다!