Início / user-255381

pramod's questions

Martin Hope
pramod
Asked: 2023-11-17 16:01:47 +0800 CST
  • 6

Tenho uma consulta que seleciona valores distintos de uma tabela e notei que o tempo de execução diminuiu significativamente após a execução inicial.

Aqui está a consulta e o plano de execução correspondente que obtive quando executei a consulta pela segunda vez.

    EXPLAIN ANALYZE SELECT DISTINCT integration_type FROM my_schema.my_table;
    
    Unique (cost=0.43..576843.69 rows=7 width=2) (actual time=0.032..2826.863 rows=8 loops=1)
    -> Index Only Scan using my_index on my_schema.my_table (cost=0.43..538707.38 rows=15254521 width=2) (actual time=0.031..1881.219 rows=14730886 loops=1)
    Heap Fetches: 1381786
    Planning Time: 0.557 ms
    Execution Time: 2826.897 ms

Pela primeira vez executei a consulta, demorou mais de 30 segundos. No entanto, as execuções sucessivas demoraram consistentemente menos de 3 segundos, embora o número de buscas de heap permanecesse o mesmo e não mudasse (ainda 1.381.786).

Estou curioso para entender por que o tempo de execução diminuiu para execuções sucessivas, apesar das buscas de heap inalteradas. Isso poderia estar relacionado a mecanismos de cache ou outras otimizações que o PostgreSQL emprega?

Estou usando o PostgreSQL versão 14.9

Quaisquer insights ou sugestões sobre por que esse comportamento ocorre e como posso otimizar ainda mais a consulta ou as configurações do banco de dados serão muito apreciados.

Obrigado.

postgresql
Martin Hope
pramod
Asked: 2023-11-13 18:07:40 +0800 CST
  • 5

Estou trabalhando com PostgreSQL e tenho uma preocupação com o inchaço da tabela ao adicionar uma nova coluna a uma tabela existente. Entendo que o PostgreSQL usa Multi-Version Concurrency Control (MVCC) e autovacuum para recuperar espaço de linhas antigas.

Aqui está o cenário:

Digamos que eu tenha uma tabela nomeada example_tablecom dados existentes e decido adicionar uma nova coluna, por exemplo, new_columnde um tipo de dados maior:

ALTER TABLE example_table ADD COLUMN new_column VARCHAR(255);

Além disso, atualizarei a nova coluna com novos valores:

UPDATE example_table SET new_column = 'some_value';

Pelo que entendi, após esta operação, as linhas antigas são marcadas como mortas e o autovacuum eventualmente recuperará o espaço. No entanto, as linhas antigas eram de tamanho menor em comparação com as novas linhas com a coluna adicionada.

Tenho as seguintes perguntas:

  • Como o PostgreSQL (especificamente, Autovacuum) lida com o espaço recuperado de linhas antigas, considerando a diferença de tamanho entre as linhas antigas e as novas?
  • Esse processo levará potencialmente ao inchaço da tabela, já que as tuplas mortas não podem ser reutilizadas devido à diferença de tamanho?
  • É necessário executar um VACUUM FULL para recuperar espaço com eficiência em tal cenário, ou o autovacuum lidará com isso de forma adequada?
postgresql