Tiago, Algo como sua idéia poderia servir. Por agora, tenho outros problemas para resolver na funcão, e estou deixando esse de lado, e simplesmente reordenando a cada iteração (não é o principal bottleneck em termos de performance, de qualquer forma...).
Agradeço muito as sugestões dadas. Atenciosamente, Rodrigo Sperb 2009/11/7 <[email protected]> > Send pgbr-geral mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of pgbr-geral digest..." > > > Tópicos de Hoje: > > 1. Re: Ter uma tabela com ordem sempre mantida (Tiago Adami) > 2. Re: Ter uma tabela com ordem sempre mantida > (Euler Taveira de Oliveira) > 3. Re: Ter uma tabela com ordem sempre mantida (Andre Fernandes) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 7 Nov 2009 00:36:04 -0200 > From: Tiago Adami <[email protected]> > Subject: Re: [pgbr-geral] Ter uma tabela com ordem sempre mantida > To: Comunidade PostgreSQL Brasileira > <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="utf-8" > > Certo JotaComm, concordo com sua posição, mas durante a minha sugestão não > tinha informações para dar a melhor solução. > > Mas continuando, a questão que me veio à cabeça inicialmente é de quantos > registros existem no universo deste problema, e em qual intervalo de tempo > a > fila recebe ou perde registros que exijam uma nova reorganização. > > Como não sabemos ainda se o desempenho é baixo na execução da função de > ordenação ou durante a atualização dos registros na tabela (Rodrigo por > favor nos diga) eu sugeri a criação do índice clusterizado. Porém, após > reler os posts do Rodrigo, me veio à cabeça uma solução que encontrei muito > tempo atrás para resolver um problema parecido, onde a cada nova linha > inserida era necessário reorganizar quase todos os registros de uma tabela > de "chamados", que possuíam um número único de prioridade na fila > determinando a ordem de atendimento. > > Nesta ocasião eu utilizava uma pesquisa binária começando do fim ao início > da fila para encontrar em qual parte o registro seria encaixado. Após isto, > todos os registros do ponto de inserção até o início da fila eram > atualizados para receber o novo valor de prioridade (maior prioridade, > início da fila). Exemplo: > > Prioridade, Registro > 8, A > 7, B > 6, C > 5, D > 4, E > 3, F > 2, G > 1, H > > Inserindo registro BA com prioridade 7 (valor definido pelo aplicativo > segundo regras pré-estabelecidas): Neste caso pesquisaria: BA >= H, depois > BA >= D e por fim BA >= B, sendo este último a condição satisfatória da > pesquisa binária. Então ficaria: > > Prioridade, Registro > 8, A > 7, B > 7, BA -- O registro entrou aqui > 6, C > 5, D > 4, E > 3, F > 2, G > 1, H > > Mas o campo "prioridade" não poderia ter valores repetidos, então era feito > um algoritmo de atualização para recalcular a prioridade de todos que no > final resultava: > > Prioridade, Registro > 9, A > 8, BA -- por ser mais recente, passou à frente do registro "B" (regra de > negócio) > 7, B > 6, C > 5, D > 4, E > 3, F > 2, G > 1, H > > O problema disso tudo era que o número de registros na fila beirava os > 1.000 > (isso mesmo, hum mil), mas como a tabela possuía um grande número de > colunas > indexadas e triggers disparadas a cada update, a atualização direta era > muito lenta. Bolei então uma solução bem simples para o problema, criando > uma tabela auxiliar chamada "chamado_prioridade" que mantinha apenas as > colunas "Prioridade" e "Registro" (que na verdade tinha outro nome e era a > chave primária da tabela de chamados). > > A stored procedure era executada, e cada registro reorganizado era gravado > em uma tabela temporária, idêntica à "chamado_prioridade". Após reorganizar > todos os registros, o processo finalizava com: > > DELETE FROM chamado_prioridade; > INSERT INTO chamado_prioridade( prioridade, registro ) SELECT prioridade, > registro FROM chamado_prioridade_tmp; > DROP TABLE chamado_prioridade_tmp; > > E isso deu um ganho de tempo antes inimaginável no processo, pois em média > a > cada 5 minutos um novo chamado entrava na fila. > > Bem, por mais ridículo que esta minha "solução" possa ser, espero que > alguma > idéia possa ser aproveitada. Não sei como esta solução se comportaria com > milhares ou milhões de registros... > > P.S: Quando um chamado era atendido, ele era removido da fila (causando > nova > reorganização). Ou seja, o tamanho da fila nunca seria de 0 para o > infinito, > variava entre 1 e pouco mais de 1000. > > -- > TIAGO J. ADAMI > http://www.adamiworks.com > > > 2009/11/5 JotaComm <[email protected]> > > > Olá, Tiago > > > > O custo disso é que para cada inserção é necessário clusterizar novamente > a > > tabela a partir do índice, pois a cada inserção é provável que o registro > vá > > para o final da tabela. > > > > 2009/10/26 Tiago Adami <[email protected]> > > > > Talvez clusterizar um índice nesta tabela ajude no desempenho, já que os > >> dados serão reorganizados a cada registro gravado [1]. Assim, a ordem > >> retornada será sempre a mesma de um ORDER BY sobre a mesma coluna. > >> > >> Na verdade não sei muito o que dizer, isso foi um *chute*. Fica um tanto > >> abstrato tentar dar alguma opinião sem um exemplo. Se puder exemplificar > >> alguma coisa seria mais fácil. > >> > >> [1] http://www.postgresql.org/docs/8.4/static/sql-cluster.html > >> > >> -- > >> TIAGO J. ADAMI > >> http://www.adamiworks.com > >> > >> 2009/10/26 Rodrigo Sperb <[email protected]> > >> > >>> Olá a todos, > >>> > >>> > >>> Eu tenho uma função implementada em PL\PgSQL que itera sempre pegando a > >>> linha do topo após ordenar por uma certa coluna. Isso se repete em > todas > >>> iterações, e como faço atualizações nessa tabela (é uma "priority > queue", > >>> para quem é familiarizado com notação matemática...) no intermédio, não > >>> possa ter a ordenação pré-estabelecida e sempre pegar o topo > simplesmente... > >>> Preciso reordenar sempre. > >>> > >>> Acontece que isso leva algum tempo e eu preciso melhorar a performance > do > >>> meu algoritmo. Ele é parte da minha tese de mestrado aqui na Holanda. > Meu > >>> orientador me comentou que poderíamos ter as posições pré-definidas e > fazer > >>> atualizações "inteligentes", mantendo cada registro na devida posição > que > >>> deve ocupar... Mas ele ainda não me disse nada de como fazer. Queria, > então, > >>> saber se alguém tem alguma idéia de como se pode fazer algo assim? > >>> > >>> Desde já agradeço. > >>> > >>> Rodrigo Sperb > >>> > >>> _______________________________________________ > >>> pgbr-geral mailing list > >>> [email protected] > >>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > >>> > >>> > >> > >> > >> > >> > >> _______________________________________________ > >> pgbr-geral mailing list > >> [email protected] > >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > >> > >> > > > > []s > > -- > > JotaComm > > http://jotacomm.wordpress.com > > > > _______________________________________________ > > pgbr-geral mailing list > > [email protected] > > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > > > > -------------- Pr?a Parte ---------- > Um anexo em HTML foi limpo... > URL: > http://listas.postgresql.org.br/pipermail/pgbr-geral/attachments/20091107/1602d443/attachment.html > > ------------------------------ > > Message: 2 > Date: Sat, 07 Nov 2009 00:36:09 -0200 > From: Euler Taveira de Oliveira <[email protected]> > Subject: Re: [pgbr-geral] Ter uma tabela com ordem sempre mantida > To: Comunidade PostgreSQL Brasileira > <[email protected]> > Message-ID: <[email protected]> > Content-Type: text/plain; charset=UTF-8 > > Tiago Adami escreveu: > > Mas continuando, a questão que me veio à cabeça inicialmente é de > > quantos registros existem no universo deste problema, e em qual > > intervalo de tempo a fila recebe ou perde registros que exijam uma nova > > reorganização. > > > Por que não utilizar simplesmente o _fillfactor_? Manter uma tabela > ordenada é > uma tarefa árdua (principalmente se essa tabela sofre muitas modificações). > > > -- > Euler Taveira de Oliveira > http://www.timbira.com/ > > > ------------------------------ > > Message: 3 > Date: Sat, 7 Nov 2009 07:27:43 -0200 > From: Andre Fernandes <[email protected]> > Subject: Re: [pgbr-geral] Ter uma tabela com ordem sempre mantida > To: Comunidade PostgreSQL Brasileira > <[email protected]> > Message-ID: > <[email protected]> > Content-Type: text/plain; charset="iso-8859-1" > > Euler, > Desculpa a ignorância, mas o que é o _fillfactor_? > > 2009/11/7 Euler Taveira de Oliveira <[email protected]> > > > Tiago Adami escreveu: > > > Mas continuando, a questão que me veio à cabeça inicialmente é de > > > quantos registros existem no universo deste problema, e em qual > > > intervalo de tempo a fila recebe ou perde registros que exijam uma nova > > > reorganização. > > > > > Por que não utilizar simplesmente o _fillfactor_? Manter uma tabela > > ordenada é > > uma tarefa árdua (principalmente se essa tabela sofre muitas > modificações). > > > > > > -- > > Euler Taveira de Oliveira > > http://www.timbira.com/ > > _______________________________________________ > > pgbr-geral mailing list > > [email protected] > > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > > > > > -- > André de Camargo Fernandes > -------------- Próxima Parte ---------- > Um anexo em HTML foi limpo... > URL: > http://listas.postgresql.org.br/pipermail/pgbr-geral/attachments/20091107/c58868db/attachment-0001.htm > > ------------------------------ > > _______________________________________________ > pgbr-geral mailing list > [email protected] > https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral > > > Fim da Digest pgbr-geral, volume 33, assunto 18 > *********************************************** >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
