Início / dba / Perguntas / 212195
Accepted
Erwin Brandstetter
Asked: 2018-07-14 15:43:29 +0800 CST

Declarar a volatilidade da função IMUTÁVEL pode prejudicar o desempenho?

  • 772

As funções do Postgres são declaradas com classificação de volatilidade VOLATILE, STABLEouIMMUTABLE . O projeto é conhecido por ser muito rigoroso com esses rótulos para funções internas. E com razão. Exemplo proeminente: os índices de expressão permitem apenas IMMUTABLEfunções e essas devem ser verdadeiramente imutáveis ​​para evitar resultados incorretos.

As funções definidas pelo usuário ainda podem ser declaradas conforme a escolha do proprietário. O manual aconselha:

Para obter melhores resultados de otimização, você deve rotular suas funções com a categoria de volatilidade mais estrita que seja válida para elas.

... e adiciona uma extensa lista de coisas que podem dar errado com um rótulo de volatilidade incorreto.

Ainda assim, há casos em que fingir imutabilidade faz sentido. Principalmente quando você sabe que a função é, de fato, imutável dentro do seu escopo. Exemplo:

Deixando de lado todas as possíveis implicações na integridade dos dados , qual é o efeito no desempenho? Pode-se supor que declarar uma função IMMUTABLEsó pode ser benéfico para o desempenho . É assim mesmo?

Declarar a volatilidade da função pode IMMUTABLE prejudicar o desempenho?

Vamos assumir o Postgres 10 atual para reduzi-lo, mas todas as versões recentes são interessantes.

postgresql performance

1 respostas

  1. Best Answer

    Sim, pode prejudicar o desempenho.

    Funções SQL simples podem ser "embutidas" na consulta de chamada. Citando a Wiki do Postgres :

    As funções SQL (ou seja LANGUAGE SQL, ) terão, sob certas condições, seus corpos de função embutidos na consulta de chamada em vez de serem invocados diretamente. Isso pode ter vantagens substanciais de desempenho, pois o corpo da função fica exposto ao planejador da consulta de chamada, que pode aplicar otimizações como dobra constante, empilhamento de qualidade e assim por diante.

    Minha ênfase em negrito .

    Para impor a correção, há uma série de pré-condições. Um deles :

    se a função for declarada IMMUTABLE, a expressão não deverá invocar nenhuma função ou operador não imutável

    Ou seja, as funções SQL que usam quaisquer funções não imutáveis, mas que ainda estão sendo declaradas IMMTUTABLE, são excluídas dessa otimização. Acionado por essas respostas relacionadas no SO, tenho executado testes extensivos:

    Basicamente comparando essas duas variantes de uma função SQL simples (mapeamento de datas para um integer, ignorando o ano que não importa para o propósito):

    CRIAR FUNÇÃO f_mmdd_tc_s(data)
  RETORNOS int
  IDIOMA sql STABLE     AS
$$SELECT to_char($1, 'MMDD')::int$$;

CRIAR FUNÇÃO f_mmdd_tc_i(data)
  RETORNOS int
  IDIOMA sql IMUTÁVEL AS
$$SELECT to_char($1, 'MMDD')::int$$; -- não pode ser embutido!

    A função Postgres to_char()é apenas STABLE, não IMMUTABLE(todas as instâncias sobrecarregadas dela - por motivos além do escopo desta resposta ). Então o segundo é falso IMMUTABLEe acaba sendo 5x mais lento em um teste simples:

    db<>fique aqui

    Este exemplo específico pode ser substituído pelo equivalente:

    CREATE FUNCTION f_mmdd(date)
  RETURNS int
  LANGUAGE sql IMMUTABLE AS
'SELECT (EXTRACT(month FROM $1) * 100 + EXTRACT(day FROM $1))::int';

    Pareceria mais caro com duas chamadas de função e mais cálculos. Mas o IMMUTABLErótulo é verdadeiro (além disso, a função usada é mais rápida e coagir é textmais integercara também).

    2x mais rápido que a variante mais rápida acima (10x mais rápido que a mais lenta). O ponto é: Use IMMUTABLEfunções sempre que possível , então você não precisa "trapacear" para começar.

    • 10

relate perguntas