Bom dia, criei uma base de dados para testes de performance com uma
tabela contendo 2 milhões de registros contendo um campo text com texto
gerado aleatoriamente com 25 palavras cada.
A base de dados ficou com 2,5GB, estou utilizando shared_buffers de
3.5GB para que a base fique toda em cache.
Na verdade aqui há um engano.
Você dimensionou um shared_buffers onde *provavelmente* uma grande parte
da tabela vai caber no cache do PostgreSQL.
O que todo mundo esquece é que, quando usamos muita memória para o
PostgreSQL, não sobra nada pro cache do disco no Linux. Esse cache do
disco é muito importante, pois ele costuma ser mais eficiente do que o
cache do PostgreSQL, e o PostgreSQL aproveita bem isso.
Utilizando consultas para testes de performance percebo que sempre que
altero o texto a ser pesquisado a primeira consulta fica lenta, a
próximas ficam abaixo de 1 segundo. Exemplo de filtro:
to_tsquery('teste|porta|janela')
Você tem índices aí?
Você tem outras tabelas?
Enfim, seu teste me parece mais uma rota de colisão com uma parede do
que um teste. É muito simples e não corresponde ao uso real de um banco
de dados.
Minha dúvida é como a tabela é armazenada em cache, em partes?
porque se a tabela fosse toda para cache não justificaria a lentidão na
primeira consulta.
Quem vai pro cache do PostgreSQL são páginas, eventualmente uma tabela
inteira, lembrando que há o cache do S.O. a considerar.
Obs.: já estou utilizando índice gin na coluna pré-processada do tipo
tsvector.
Índices também ocupam espaço do cache. Índices GIN costumam ser grandes.
[]s
Flavio Gurgel
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
