Em 22/06/07, Leandro Guimaraes Faria Corcete DUTRA <[EMAIL PROTECTED]>
escreveu:
Em Sex, 2007-06-22 às 10:25 -0300, Welington R. Braga escreveu:
[corte]
O Contrib costuma ser empacotado pelas distros também.
Vou da uma olhada no Debian (minha distro)
Bem, já sentaram o pau nos links que passei - opinião é opinião e não
> estou criticando, mesmo porque estou entrando nesta questão agora - ,
> porque referem-se ao auto-relacionamento e alguns até citaram o método
> do Fabin Pascal, mas não achei nenhum link a respeito do método dele.
>
> Alguém pode me passar algum?
Infelizmente não lembro agora. Você pode procurar em
http://dbdebunk.com./, que está inativo mas ainda tem os arquivos; de
outro modo, teria de comprar o livro. Mas não tem muito segredo, é só
evitar o auto-relacionamento que é meio feio, fazendo uma tabela com os
dados e outra com os pares pai–filho.
Dei uma procurada lá e não achei, vou olhar depois com mais calma, mas já vi
que vou ter que comprar alguns livros.
A priori o autorelacionamento pareceu-me bem atraente por simplificar
> a consulta e agilizar o retorno dos dados de saída. Mas realmente
> torci o nariz para o fato de ter que dar um 'update' em quase toda
> árvore quando precisar incluir um novo taxon.
O que é um taxon?
http://pt.wikipedia.org/wiki/T%C3%A1xon
Resumindo: Qualquer pedaço da sua árvore. (Cada tupla, na tabela e que seja
parte da árvore)
Mas no auto-relacionamento isso não é necessário, só no modelo
maluco
do maluco do Celko.
Sincerametne confesso que não vi diferença entre o Celko e o
autorelacionamento. Vou dar uma olhada com mais carinho, ao invés de só ver
as figuras e o código SQL ;-)
Se eu tiver várias pessoas acrescentando dados na árvore vai ser um
> caos e para evitá-lo teria que dar um lock em toda a tabela para
> impedir que bagunçem os relacionamentos,
Não, use controle de transações.
[possivel bobagem] Mas as funções em pgplsql, não são executadas em uma
única transação? [/possivel bobagem]
Sinceramente, agora eu fiquei mais perdido que cego em tiroteio. Eu
> dei uma dobrada nos valores dos meus shared_buffer e o max_fsm_pages
> além de limitar o tempo do tcp_keepalives_idle para 2h, o que está de
> bom tamanho. E pra completar, depois de um 'vacuum full analize' que
> levou mais de 30m sendo 10m só na bendita tabela da árvore parece que
> as coisas normalizaram provisoriamente.
Ah, isso explica muita coisa. Que tal deixar agendado um
periódico?
Deve demorar bem menos se for, por exemplo, semanal ou até mensal. E se
você fizer, por exemplo diariamente, um mais /light/.
É, eu já tinha uma vacuum full agendado diariamente, mas não com analize.
vou por este comando para executar semanalmente.
--
Welington Rodrigues Braga
--------------
Web: http://gtk-br.welrbraga.t5.com.br
MSN: welrbraga[*]msn·com
Gtalk: welrbraga[*]gmail·com
Yahoo / Skype: welrbraga
ICQ: 52789331
"Em tudo somos atribulados, porém não angustiados; perplexos, porém não
desanimados; perseguidos, porém não desamparados; abatidos, porém não
destruídos;" - 2Co 4:8,9
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
