Joe's questions

É difícil encontrar um título adequado para isso, portanto, quaisquer sugestões e edições são bem-vindas.

Ao ANALISAR um plano, você é informado quando determinados nós emitiram a primeira linha e quando emitiram sua última linha. Alguns nós podem começar a operar mesmo sem ter o conjunto de resultados completo (um loop aninhado que faz uma pesquisa de índice recebendo linhas de um nó interno pode teoricamente já começar a fazer isso antes mesmo do nó interno ser totalmente avaliado, quando o nó interno já está retornando um subconjunto dos resultados).

Eu posso ver essas actual timessobreposições nas avaliações, o que significa que alguns nós já devem começar a ser avaliados antes mesmo de terminar os nós internos.

Minhas perguntas:

• Todos os nós (a menos que um nó de processamento paralelo seja especificado) são executados sequencialmente, o que significa que eles só começam a trabalhar quando o nó interno é concluído? (nota: considerando as sobreposições de tempo reais na análise, acho que não)
• Se eles não são executados sequencialmente, mas apenas executados em um único thread, eles são otimizados para IO, como em, enquanto um nó interno está fazendo algo pesado em IO, é um nó externo fazendo cálculos, se possível, e retornando assim que o nó interno está pronto?
• Ou, alternativamente, eles realmente têm apenas vários threads, um para cada nó, sendo ativados assim que tiverem algo para fazer?

Sei que internamente as coisas são mais complicadas do que isso, mas acho que esta é uma boa explicação de alto nível dos meus pensamentos.

Estou em uma situação peculiar:

Eu tenho vários índices com expressões que usam uma função. Quero trocá-los para uma função diferente, onde posso garantir que a função se comporte da mesma forma (para que os valores indexados não sejam inválidos). Idealmente, não quero descartar o índice existente e reindexá-lo, porque isso requer mais sobrecarga de desenvolvimento.

Eu posso ver na pg_indextabela, há uma indexprscoluna, que contém a definição "interna" de um índice (a pg_indexestabela é uma versão muito impressa disso). Especificamente, acho que identifiquei os índices relevantes para ter um formato nos moldes de ({FUNCEXPR :funcid 870 :funcresulttype 25 :funcretset false...

Voltando funcid 870para o information_schema.routines, consegui correlacioná-lo no specific_name(que contém esse funcid) e pude determinar que é de fato a função específica que quero alterar.

Seria - teoricamente - possível substituir esse funcid pelo novo funcid e os índices então se refeririam à nova função? Como eu faria isso, já que esta coluna é do tipo pg_node_tree? Se não, existe uma maneira de atingir meu objetivo de uma maneira não hackeada?

Adendo: Provavelmente ainda farei isso da maneira "limpa", a menos que haja uma maneira segura e comprovada de fazer isso, mas isso despertou meu interesse o suficiente para fazer uma pergunta sobre isso.

Um exemplo bem prático:

Suponha uma tabela User que tenha uma coluna "excluída" que armazena carimbo de data/hora. Suponha que exista um filtro "excluído NÃO É NULO" em praticamente todas as consultas que acessam essa tabela. Este campo muito raramente não é nulo e, quando é, geralmente é de curta duração.

Perguntas:

• É necessário um índice? Embora a entropia desta coluna seja geralmente 1, não acho que o Postsgresql acompanhe a entropia sem criar um índice, o que significa que precisaria fazer uma varredura completa da tabela para cada consulta (provavelmente como a última operação, mas ainda ai!)
• Faz sentido pré-otimizar esse índice para ser um índice de hash em vez de um índice B, supondo que eu não precise de todos os operadores adicionais do índice B? Como a entropia está próxima de 1, não acho que haja uma grande diferença de tamanho entre os dois índices e, portanto, um B-Index seria superior.

Atualmente estou trabalhando na implementação de uma segurança de 2 camadas, o que significa que temos filtragem de consulta orm em nosso código de aplicativo, bem como em nosso banco de dados. No banco de dados estou usando o Postgre Row Level Security.

Em um mundo ideal, todas as consultas de filtragem criadas no código do aplicativo são perfeitas e as políticas de segurança em nível de linha nunca removem entradas. No entanto, se acontecer de filtrar um resultado, isso significa que temos um erro em nossa filtragem no código do aplicativo que deve ser corrigido. Eu gostaria de poder registrar isso.

É possível configurar o Postgresql para que eu possa ser notificado/registrar essas ocorrências?

A situação:

O líder do nosso projeto decidiu usar um banco de dados altamente normalizado como nosso design de banco de dados. O que significa que literalmente todos os campos de uma tabela grande são um ID em vez do valor real. Sua intenção é não ter duplicatas de qualquer tipo, mesmo em lugares onde duplicatas não machucam (primeiros nomes de pessoas, esse tipo de coisa).

No entanto, isso leva a um problema: ao inserir novos dados, precisamos verificar cada subtabela para ver se o valor existe (primeira consulta) e inseri-lo se não existir (segunda consulta) ou então recuperar o ID, fazer isso para literalmente todas as colunas da tabela principal (então 30 vezes ou algo assim), e então podemos criar o objeto que realmente queríamos obter. (São ~60 acessos ao banco de dados para criar um objeto!).

Trabalhamos na primavera, então usamos jdbcTemplate para construir uma conexão de banco de dados, e cada consulta é cara. Quando estamos inserindo milhares de novos registros ou atualizando-os, isso na verdade torna o banco de dados muito lento.

Todo esse processo parece completamente sujo e errado para mim e, portanto, queria perguntar: existe uma maneira melhor? É possível fazer uma subconsulta inserir um valor se não existir, ou não, se existir, e retornar a chave real em ambos os casos, que é usada imediatamente para definir o ID na tabela principal? Existe uma solução elegante para reduzir o número de consultas sem introduzir muito SQL complicado (para o bem dos membros da equipe)?

Digamos que eu tenha esse esquema de banco de dados simplificado.

O esquema consiste em três tabelas, rua, cidade e CEP que têm uma relação muitos-para-muitos entre si.

O que eu quero fazer é uma previsão que consulte o banco de dados para possíveis correspondências, além de prever dados ausentes. Para colocar mais em um exemplo: digamos que o usuário comece a digitar uma cidade, talvez "Wash". Ele já tinha uma rua digitada, para eu não conhecer nenhuma rua, vamos chamar de "New Street Avenue". Esta é uma restrição , o que significa que deve ser cumprida em nossa previsão. Agora quero que a cidade consulte possíveis finalizadores de "Wash", bem como forneça dados ausentes, neste caso, CEPs, que tenham uma rua chamada "New Street Avenue"

Veja como seria a abordagem ingênua:

1. Filtre a rua para todas as chaves cujo nome corresponda a "New Street Avenue"
2. Filtre street_city para todas as chaves da rua e retorne as chaves da cidade
3. Inner junte as chaves da cidade em city_zipcode e, em seguida, Inner junte-as no código postal

O problema com esta abordagem: O conhecimento entre rua e código postal é completamente ignorado. Isso significa que podemos acabar com CEPs e pares de cidades, onde sabemos que a cidade contém a rua que procuramos, mas o CEP não necessariamente . Esta seria uma previsão inválida para retornar, pois o endereço não existe!

Isso significa que preciso "persistir" as informações sobre a rua mais adiante.

Minha abordagem seria esta :

1. Filtre a rua em busca das chaves que cumprem nossa condição.
2. Inner Junte a rua na cidade para as chaves de #1. Mantenha ambas as colunas-chave.
3. Inner join no city_zipcode mantendo as chaves do código postal também
4. Filtre todos os pares de rua e CEP que não estão presentes em street_zipcode

(Em uma nota lateral: para "esperar" melhorar o desempenho, após cada "previsão", eu colocaria um comando LIMIT 10 (ou similar), pois precisamos apenas de uma quantidade sensata de previsões).

Essa abordagem deve funcionar. Pode não ser o melhor otimizado, mas retornaria os resultados corretos. No entanto, isso não apenas parece muito sujo para mim, mas também abre outro problema:

Tenho certeza de que escala horrivelmente, tanto no tamanho da mesa quanto nas tabelas adicionais

Há uma boa probabilidade de que haja outra tabela que tenha relacionamentos muitos para muitos, para fins de argumento, rua e CEP. Agora, se eu quiser pesquisar uma cidade com restrição de rua, preciso fazer o que fiz acima e adicionar ainda mais para filtrar também quaisquer relações entre rua e a nova tabela.

Sinto que estou entrando em um beco sem saída com essa abordagem. Eu adoraria alguém para me ajudar aqui sobre como abordar este problema melhor.