Início / dba / Perguntas / 80129
Accepted
Luan Huynh
Asked: 2014-10-15 02:37:10 +0800 CST

Processamento de consultas no back-end (E/S no disco)

  • 772

Tenho uma tabela com 100k linhas criada no PostgreSQL 9.3

create table demo_bbb
(
  id numeric NOT NULL,
  code_bbb character varying,  
  column_02 character varying,  
  column_03 character varying,  
  column_04 character varying,  
  column_05 character varying,  
  column_06 character varying,  
  column_07 character varying,  
  column_08 character varying,  
  column_09 character varying,  
  column_10 character varying,  
  CONSTRAINT demo_bbb_pk PRIMARY KEY (id)
);

Aqui está o meu teste (cada consulta é executada 3 vezes):

(1) select id from demo_bbb b ;         -- database query time: ~26ms
(2) select column_10 from demo_bbb b ;  -- database query time: 46ms, 48ms, 51ms
(3) select column_05 from demo_bbb b ;  -- database query time: 37ms, 38 ms, 45ms
(4) select * from demo_bbb b ;          -- database query time: 28ms, 32ms, 37ms

Resultado: Tempo médio de (4) < tempo de (2), (3) ( 32ms < 45ms )

Explique analise:

(1) "Seq Scan on demo_bbb b  (cost=0.00..4425.00 rows=100000 width=6) (actual time=0.008..22.088 rows=100000 loops=1)"
(2) "Seq Scan on demo_bbb b  (cost=0.00..4425.00 rows=100000 width=24) (actual time=0.008..38.702 rows=100000 loops=1)"
(3) "Seq Scan on demo_bbb b  (cost=0.00..4425.00 rows=100000 width=24) (actual time=0.008..32.098 rows=100000 loops=1)"
(4) "Seq Scan on demo_bbb b  (cost=0.00..4425.00 rows=100000 width=232) (actual time=0.007..17.702 rows=100000 loops=1)"

Estou curioso para saber o que aconteceu, mas não consigo entender. Você poderia me dar algumas explicações de como foram essas consultas?

Observação: rastreei essas consultas usando o SQL Profiler (faça o download do Enterprisedb)

postgresql profiler

1 respostas

  1. Best Answer

    Praticamente um WAG porque você não mostrou EXPLAIN (BUFFERS, OUTPUT)dados, mas:

    select id from demo_bbb b; -- database query time: ~26ms

    Se você estiver no 9.2 ou mais recente, isso provavelmente fez uma varredura somente de índice no índice exclusivo usado para implementar a restrição de chave primária. Considerando os últimos tempos, esse é o caso mais provável; se tivesse feito um seqscan (como faria em versões mais antigas), você teria resultados mais rápidos de consultas posteriores.

    select column_10 from demo_bbb b ;  -- database query time: 46ms, 48ms, 51ms
select column_05 from demo_bbb b ;  -- database query time: 37ms, 38 ms, 45ms
select * from demo_bbb b ;          -- database query time: 28ms, 32ms, 37ms

    É provável que eles estejam fazendo seqscans e, possivelmente, buscando TOAST fora de linha.

    Os tempos diferentes serão em parte devido aos efeitos de cache, possivelmente parcialmente compensados ​​pela necessidade de ler mais dados TOAST fora de linha quando você selecionar mais colunas.

    O PostgreSQL usa dois níveis de cache - o cache de disco do sistema operacional e seu próprio arquivo shared_buffers. Ambos são caches de bloco. Ele não possui um cache de resultados de consulta.

    Para obter mais informações, consulte o manual do PostgreSQL e os recursos existentes sobre benchmarking, ajuste, comportamento de cache do PostgreSQL, etc.

    • 1

relate perguntas