Pessoal, sempre lembrando, vamos evitar "top posting" com este meu comentário aqui, isto atrapalha muito!!!
Em 14 de outubro de 2016 01:55, Fernando Franquini 'capin' < fernando.franqu...@gmail.com> escreveu: > Euler, > > Eu trabalhei bastante com Oracle e SQL Server, posso afirmar que faziam > diferença e concordo com os pontos (i) e (ii). > > Porém em relação a junção fiquei em dúvida no item (iii): > > Se a PK da tabela A é FK na tabela B, ao realizar a junção de A com B e > usar a coluna FK vai usar o indice da PK na A e na B nada?? > > Obrigado pelas colocações. > Abraços. > > 2016-10-13 11:16 GMT-03:00 Euler Taveira <eu...@timbira.com.br>: > >> On 13-10-2016 08:37, Fernando Franquini 'capin' wrote: >> > Mas em princípio ele deve fazer mais bem que mal, porque? Porque toda >> > junção com as chaves (FKs) que forem realizadas irão utilizar esse >> índice. >> > >> Isso pode ser verdade em outros bancos (que criam índice para cada FK); >> no postgres isso não é. É uma prática comum (criar esses índices) mas eu >> particularmente não recomendo porque (i) ocupa espaço, (ii) torna >> operações de INSERT, UPDATE e DELETE lentas (porque é necessário manter >> os índices atualizados) e (iii) junções vão usar o índice da chave >> primária e não o índice da FK. Quando esses índices são úteis? Em >> consultas que não fazem a junção com a tabela da chave primária e a >> cláusula WHERE inclui o campo da FK (e os valores utilizados são >> seletivos). >> >> Nos diversos modelos que trabalhei atrevo a dizer que menos de 2% das >> consultas vão se beneficiar de um índice em um campo que é FK. Portanto, >> eu prefiro ir criando esses índices em FK sob demanda. Em modelos >> consolidados, faz-se uma análise de todas as consultas e os planos de >> execução vão dizer se o índice na FK é benéfico ou não. >> >> Em modelos migrados de outros SGBDs, após uma análise de uso, observa-se >> que a maioria dos índices candidatos a remoção são em FK. > > Com relação a questão de se criar indices para restrições de chave estrangeira, como o Eula já colocou isso é desnecessário na maioria dos casos. Onde seria interessante se criar? Cito aqui 3 situações que ajudam: - Quando você tem operações em cascata. Isso vai ajudar na melhoria de performance e de fato pode ser dramática a diferença de performance. - Quando a junção é no sentido da tabela pai para a tabela filha. Como já dito também, nem toda junção vai fazer uso do índice na tabela filha. Por exemplo quando a junção é no sentido da tabela filha para a tabela pai vai fazer uso do índice de chave na tabela pai pois os registros da tabela filha já foram pré-selecionados. No caso de uma junção onde se busca no sentido da tabela pai para a filha o otimizador pode fazer a escolha por utilizar o índice em casos onde haja um bom nível de seletividade o que melhora a performance. Como as operações acima não são frequentes, por exemplo é muito mais comum pesquisar um produto e fazer a junção dele com a categoria do que pesquisar a categoria e trazer todos os produtos vinculados. Aqui mesmo com índice dependendo da seletividade o otimizador pode escolher não fazer uso do índice. Portanto, se você altera com frequência a chave primária, remove os registros da tabela pai com frequência ou seleciona os registros partindo da tabela pai pra tabela filha com frequência e o índice possui índice de seletividade suficiente então um índice faria sentido. Lembro que operações em cascata são perigosas e, EU (opinião pessoal aqui) particularmente não recomendo. Sem contar que são raros os casos onde realmente são necessárias. Charly Batista
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
