Como as palavras-chave IMMUTABLE, STABLE e VOLATILE afetam o comportamento da função?

A palavra-chave IMMUTABLE é nunca adicionados automaticamente pelo pgAdmin ou Postgres. Quem criou ou substituiu a função fez isso.

A volatilidade correta para a função fornecida é VOLATILE (também o padrão), não STABLE - ou não faria sentido usar clock_timestamp() que é VOLATILE em contraste com now() ou CURRENT_TIMESTAMP que são STABLE :aqueles retornam o mesmo timestamp dentro da mesma transação. O manual:

clock_timestamp() retorna a hora atual real e, portanto, seu valor muda mesmo dentro de um único comando SQL.

O manual avisa que a volatilidade da função STABLE ...

é impróprio para AFTER gatilhos que desejam consultar linhas modificadas pelo comando atual.

.. porque a avaliação repetida da função de gatilho pode retornar diferente resultados para a mesma linha. Então, não STABLE .

Você pergunta:

Você tem uma idéia de por que a função retornou corretamente cinco vezes antes de ficar no quinto valor quando definido como IMMUTABLE ?

A Wiki do Postgres:

Com 9.2, o planejador utilizará planos específicos em relação aos parâmetros enviados (a consulta será planejada na execução), exceto se a consulta for executada várias vezes e o planejador decide que o plano genérico não é muito mais caro do que os planos específicos.

Minha ênfase em negrito. Não parece fazer sentido para um IMMUTABLE função sem parâmetros de entrada. Mas o rótulo falso é substituído pelo VOLATILE função no corpo (voids função embutida ):um plano de consulta diferente ainda pode fazer sentido.

Desempenho do procedimento armazenado do PostgreSQL

À parte

trunc() é um pouco mais rápido que floor() e faz o mesmo aqui, já que números positivos são garantidos:

SELECT (trunc(EXTRACT(EPOCH FROM clock_timestamp()) * 10) - 13885344000)::int