Na
primeira parte, falamos sobre as principais inovações e mudanças no PostgreSQL 11. Desta vez, discutiremos com mais detalhes alguns pontos no formato de perguntas / respostas que foram levantados pelo meetup.
Qual é a melhor maneira de transferir uma grande matriz de dados como um conjunto de parâmetros de entrada para um procedimento armazenado no PL / pgSQL?
A maneira mais conveniente é criar uma tabela temporária, fazer cópias dos dados e usá-las no procedimento.
Mecanismos externos (zheap) e o desenvolvimento do PostgreSQL na memória
Não para todas as cargas de trabalho, um modelo com armazenamento de versões antigas de registros na própria tabela é adequado. Em todos os outros subd (versionionniki), eles são armazenados em um desfazer log. Você pode argumentar sobre a viabilidade, mas o ponto principal é que você precisa armazenar registros antigos em algum lugar. Se eles têm uma vida útil curta e alguém raramente os aborda, o armazenamento na própria tabela é prejudicial. O mecanismo zheap externo PostgreSQL é uma tentativa do EnterpriseDB de criar um mecanismo de tabela para o PostgreSQL com o log de desfazer. Funciona, embora ainda haja algo a melhorar.
Quem trabalha com a Sra. O SQL no modo de nível de isolamento SNAPSHOT, sabe que possui tempdb, onde coloca versões antigas, e está equipado com um aspirador de pó completamente para limpeza do tempdb. Por outro lado, a comunidade pede para criar tabelas na memória no PostgreSQL. Isso pode ser feito facilmente: tmpfs, e é isso. No PostgreSQL Pro, até lançou a primeira versão piloto, você pode tentar.
O que o PostgreSQL nunca teve foram os mecanismos de plug-in. Havia índices conectáveis que usavam um WAL comum. O PostgreSQL tem muito para conectar e pouco para substituir em tempo real. Por exemplo, o executor não está desabilitado, mas você já pode usar nós personalizados que você mesmo programa. Os otimizadores no PostgreSQL são completamente conectáveis. Você pode escrever o seu próprio e usar o PostgreSQL como intérprete de suas consultas. O analisador SQL não pode ser conectado.
Os mecanismos desejam conectar em três direções:
- mecanismo com desfazer log
- na memória
- armazenamento de coluna para consultas OLAP
O Postgres Pro está conversando com o EnterpriseDB sobre como criar uma API para conectar tudo isso.
Sobre chave estrangeira
A chave estrangeira dentro do PostgreSQL é implementada por gatilhos. Você pode escrever seu gatilho que implementará qualquer tipo de funcionalidade. Todas as restrições possíveis devem ser feitas no gatilho. A lógica nos gatilhos não é particularmente necessária, mas verifique tudo - é necessário.
O Postgres Pro está planejando fazer SaaS ou PaaS?
O Postgres Pro planeja tornar o PostgreSQL mais otimizado para a nuvem, em particular para implementar mudanças dinâmicas nos buffers de compartilhamento, para reduzir o número de parâmetros que exigem a reinicialização do PostgreSQL. Eles não vão construir a nuvem eles mesmos.
Como configuro uma unidade para que a indexação paralela funcione mais rápido? Qual é o melhor, vários HDDs ou um SSD?
Melhor alguns SSDs. Quanto mais opções de paralelização o hardware oferecer, melhor. Se você tiver um disco, memória insuficiente e um processador, a paralelização não ajudará. Mas os SSDs têm uma peculiaridade: eles começam a desacelerar se mais de 80% do volume estiver ocupado. Portanto, não se esqueça de ajustar o corte, caso contrário, o limite de 80% chegará a cerca de 50%.
Gerenciamento de dicionário e adição de palavras na pesquisa de texto completo
Se você usa feitiço ou bola de neve, basta alterar o dicionário da palavra final. O problema é que, se você adicionou uma palavra de parada, não faz sentido indexar. Isso pode ser feito lentamente. Uma palavra de parada será lançada fora de uma solicitação e nunca será pesquisada. E se você removeu a palavra de parada, em nenhum lugar da coleção ela não existe e é necessário reindexá-la. O problema não está no dicionário, mas no fato de que você já o usou e salvou seu conhecimento.
Além disso, em muitos casos, você pode usar a função pouco conhecida ts_rewrite, que permite substituir uma parte da solicitação por outra. Por exemplo, quando o submarino Kursk se afogou, todos correram para procurar informações sobre ele. Fedor Sigaev, na época, trabalhava em passeador e, a pedido de "Kursk", informações sobre a cidade eram fornecidas. Eles prontamente fizeram uma substituição: nesta palavra, forneça informações sobre o submarino. Mas então os usuários começaram a xingar, que estavam interessados na própria aldeia. Não sei se eles perceberam ou não, mas foi necessário introduzir a "cidade de Kursk". Tais substituições permitem que ts_rewrite seja feito. Além disso, a função pode ser usada para uma transição suave durante o período de alterações no dicionário.
Obviamente, alterar o analisador e os dicionários são tarefas complexas. Idiomas com diferentes alfabetos, como russo e inglês, se dão bem. Muito pior agora são, digamos, textos em francês-inglês. Não está claro a que idioma uma palavra se refere, que é escrita da mesma maneira, mas em um idioma é uma palavra de parada e em outro não é. O Postgres Pro está atualmente trabalhando em dicionários de ajuste fino para descrever configurações mais complexas.
Cobrindo índices e atualização quente
São completamente amigos. É verdade que, se pelo menos um campo for atualizado no índice de cobertura, o índice se comportará como de costume, tudo será substituído.
Incapacidade de criar tabelas temporárias ao executar consultas em espera
O PostgreSQL não armazena conhecimento de tabela no diretório do sistema, mas há um patch que transfere conhecimento para o diretório do sistema. Portanto, com esse patch, você pode usar tabelas temporárias. Mas então surge outro problema: não há transações em espera. Para trabalhar com uma tabela temporária, você precisará usar o ID de transação virtual duas vezes, que se aplica somente a tabelas temporárias, e não às principais que vêm do assistente. E quando você olha para um número de 32 bits, eles serão dois números diferentes.
O Postgres Pro também possui um módulo pg_variables, que também funciona em modo de espera. Esta não é uma tabela temporária, mas a funcionalidade necessária pode ser representada.
Implementar índice de cluster
O Postgres Pro teve várias tentativas para implementá-lo. Agora você pode inserir o índice da tabela de cluster e a tabela estará na mesma ordem. Sofreu com como manter uma tabela em um estado em cluster. Tentamos abordagens diferentes, mas a inserção invariavelmente em uma tabela desse tipo era muito cara. E isso não é interessante para ninguém. Portanto, até agora, concluiu-se que é necessário mudar para Tabelas Organizadas por Índice.
Fator de escala recomendado para autovacuum
Geralmente recomendo definir 1 - 5%. Mas isso é completamente opcional. Para tabelas pequenas, nas quais, apesar das alterações, em média, a mesma distribuição permanece, um valor grande pode ser definido. Se a tabela for grande e raramente reabastecida, mas adequadamente, com uma forte mudança na distribuição, você terá que inventar outra coisa. Tudo depende da distribuição dos seus dados.
Dicas em consultas complexas
No Oracle, com consultas complexas, você precisa ajudar periodicamente com dicas, porque ocorrem verificações completas repentinas. Existem dicas no Postgres Pro, bastante sombrias, mas você pode obtê-las. No entanto, não há dicas no PostgreSQL comum, e é improvável que elas apareçam. Se você possui dicas integradas, os usuários, diante de um problema do otimizador, inserem dicas, acalmam-se e não relatam um problema. O desenvolvimento do otimizador é interrompido.
A propósito, o otimizador do PostgreSQL tem um problema. Quando ele estima uma amostra de uma tabela, mesmo para uma quantidade mais ou menos razoável, ele adivinha com algum erro. Então ele começa a se conectar, o resultado é conectado a outra coisa, o erro se acumula e, no terceiro ou quarto nível, o PostgreSQL perde muito.
Existe essa configuração - limite de recolhimento de junção. O PostgreSQL classifica JOINs para uso mais eficiente, mas o limite de classificação padrão é 8. Se houver mais de 8 JOINs seguidos, o sistema não os classificará e haverá uma dependência da ordem JOIN na consulta.
Há também um otimizador genético com vários parâmetros. Você pode ativar várias configurações em uma sessão e descrever mais ou menos como a solicitação deve ser executada. Usando esta ordem, com a ajuda de colchetes, você pode definir o desligamento de algumas operações, a mesma verificação de segundo. Outra opção é inserir certos parâmetros nas funções. De certa forma, essas também são dicas. Não é muito conveniente, mas pelo menos alguma coisa.