Em Qui, 2007-06-21 às 14:31 -0300, Thiago Risso escreveu:
> > Você vem de MySQL? Parece típico de MySQL, porque ele implementa
> > subconsultas mal.
>
> Não ... É que já tive más experiencias com NOT IN... Onde o LEFT foi
> melhor, mas não me lembro exatamente a estrutura das tabelas nem
> índices...
Bom, tem o EXISTS também, que creio ser ainda mais simples.
Talvez versões antigas? Não parece haver grandes problemas com o
otimizado nas v8.
> SELECT * FROM tzrepl.tzr_log L
> LEFT OUTER JOIN tzrepl.tzr_replicated_log RL
> ON RL.id_log = RL.id_log
> WHERE RL.id_log IS NULL;
> -- 861971 registros em 24078ms
>
> SELECT * FROM tzrepl.tzr_log L
> WHERE id_log NOT IN(SELECT id_log FROM tzrepl.tzr_replicated_log)
> --861971 registros em 19407ms
Como eu suspeitava, você melhorou alguma coisa o plano de execução.
Importa-se de publicá-lo na lista?
> Achei os números bem aceitáveis [1], principalmente por estar em um
> servidor de Teste (Bem ruinzinho por sinal)... Mas meu medo é que
> conforme esse registros aumentem (e vão aumentar muito), isto comece a
> ficar muito lento...
Exato.
> Em produção eu utilizo também uma chave para filtrar os
> replicated_log, o que reduziria um pouco este número ( < 718309 ) ...
> Estava pensando em colocar mais uma coluna (num_repl) em tzr_log, que
> seria incrementada a cada registro inserido em replicated_log e assim
> poderia adicionar mais uma condição ao select para tentar diminuir o
> SCAN (num_repl < (select SUM(oid) FROM tzr_nodes) ...
> Isto é uma boa prática ?? O que sugerem ??
Não sei se entendi, mas não parece ser bom não…
> Concordo ..Mas existe como modelar de outra forma ??
Não creio. E se houver, tem de entender muito bem o problema para dar
pitaco.
> Tenho uma tabela de nós (tzr_nodes), outra de log (tzr_log) e outra de
> logs replicados (tzr_replicated_log)...
Nós 1:N replicated N:1 log?
> Quando eu insiro, altero ou deleto um registro insiro este na tabela
> de logs e replico este para o(s) nós que estão na tabela de nós e
> insiro um registro em logs replicados com o id do log e o id do nó
> para cada replicação que é efetuada com sucesso ...
Ah, é você que está tentando implementar uma replicação na unha?
Toda vez que aparece alguém com essa idéia eu aviso que é fria… não é o
primeiro, e infelizmente não será o último. Vide a entrevista que o
Telles publicou hoje.
> > O melhor dos mundos seria, por exemplo, percorrer a tzr_log e, a
> > partir
> > de seu índice, o índice da tzr_replicated_log, evitando a tabela
> > tzr_replicated_log em si.
>
> Existe como implementar isso ?
Sim… se você tem os índices adequados, e não usa dados da replicated,
mas apenas quer saber da existência ou não da chave indexada, deveria
ser automático. Se não funcionar, talvez seja o caso de verificar com
alguém mais esperto que eu, pode ser até um defeito de otimizador
(duvido).
--
Leandro Guimarães Faria Corcete DUTRA <[EMAIL PROTECTED]>
Atech Fundação Aplicação de Tecnologias Críticas SP, BR
msnim:[EMAIL PROTECTED]
skype:leandro.gfc.dutra?chat +55 (11) 3040 7300 r151
- - - - -
Politica de Privacidade: Esta mensagem pode conter informacao confidencial e/ou
privilegiada. Se voce nao for o destinatario ou a pessoa autorizada a receber
esta mensagem, nao pode usar, copiar ou divulgar as informacoes nela contidas
ou tomar qualquer acao baseada nessas informacoes. Se voce recebeu esta
mensagem por engano, por favor avise imediatamente o remetente, respondendo o
e-mail e em seguida apague-o. Agradecemos sua cooperacao.
Privacy Policy: This message may contain confidential and/or privileged
information. If you are not the addressee or authorized to receive this for the
addressee, you must not use, copy, disclose or take any action based on this
message or any information herein. If you have received this message in error,
please advise the sender immediately by reply e-mail and delete this message.
Thank you for your cooperation._______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
