foobar0100's questions

Entendo que as exibições são implementadas usando o sistema de regras, mas não tenho certeza se isso tem alguma vantagem/desvantagem ao executar o DDL transacional contra elas. A emissão CREATE OR REPLACE VIEW ...;ou DROP VIEW ...; CREATE VIEW...;em uma transação remove um ACCESS EXCLUSIVEbloqueio semelhante ao DDL em uma tabela ? Todas as consultas emitidas antes do DDL teriam que ser concluídas antes que o DDL pudesse ser executado? As consultas seriam emitidas após o bloco DDL até que o DDL fosse concluído?

De acordo com os documentos:

PL/Python está disponível apenas como uma linguagem "não confiável", o que significa que não oferece nenhuma maneira de restringir o que os usuários podem fazer nela e, portanto, é chamada de plpythonu. Uma variante confiável do plpython pode se tornar disponível no futuro se um mecanismo de execução seguro for desenvolvido em Python.

Por que exatamente é difícil desenvolver um mecanismo de execução seguro para Python, mas não para outras linguagens como Perl?

Ao ativar um servidor de espera ativa especificamente para propósitos de BI/Analytics, onde consultas longas podem ser comuns, é melhor ativar hot_standby_feedbackou definir as max_standby_*_delayconfigurações como -1?

Meu entendimento é que hot_standby_feedbackimpede o mestre de fazer coisas como VACUUMaté que seja seguro fazer o mesmo no modo de espera, onde as max_standby_*_delayconfigurações permitem VACUUMiniciar no mestre, mas o modo de espera, se necessário, aguarda para aplicar qualquer limpeza a vácuo que possa entrar em conflito com um longo consulta em execução.

Além disso, os documentos afirmam para hot_standby_feedback:

Existem possibilidades corretivas se o número de cancelamentos de consultas em espera for considerado inaceitável. A primeira opção é definir o parâmetro hot_standby_feedback, que evita que o VACUUM remova as linhas mortas recentemente e, portanto, não ocorram conflitos de limpeza. Se você fizer isso, observe que isso atrasará a limpeza de linhas mortas no primário, o que pode resultar em um inchaço indesejável da tabela. No entanto, a situação de limpeza não será pior do que se as consultas em espera estivessem sendo executadas diretamente no servidor primário, e você ainda obteria o benefício de descarregar a execução no modo de espera.

E para max_standby_*_delayos documentos, estado:

Se o servidor em espera for designado como um servidor adicional para consultas de suporte à decisão, pode ser aceitável definir os valores máximos de atraso para muitas horas ou até mesmo -1, o que significa aguardar indefinidamente a conclusão das consultas.

Ainda não está claro para mim qual é o melhor e quais são os prós e contras exatos de cada um.

Em uma palestra re:Invent de 2015, a AWS mencionou que o vácuo deve ser executado não apenas após atualizações ou exclusões, mas também após inserções. Aqui está a parte relevante da palestra:

http://www.youtube.com/watch?v=tZXp19q8RFo&t=16m2s

Supostamente, há alguma limpeza que deve ser feita nos blocos, mesmo que eles tenham recebido apenas inserções e essa limpeza pode ser feita na primeira vez que um bloco é selecionado (diminuindo a leitura) ou durante o vácuo. Isso é verdade e, em caso afirmativo, exatamente qual limpeza deve ser feita?

De onde o tipo de dados obteve seu nome? Loja de hash?