Olha, vou te atazanar neste assunto Essa cultura que vem de aplicações Desktop, lá dos primordios dos DBFs onde se usavam TTables, cultura muito usada no Clipper também. Entendo que é muito bom você trabalhar com registros em Cache, mas hoje em dia com o numero de informações que trabalhamos não é viável. Você não só prejudica o usuário da maquina que quer todos esses registros, como toda a rede. Imagino que você deve estar usando Query.Filter, é rápido quando o grid já está carregado, mas com o tempo sua aplicação vai começar a travar legal. Eu já tive este problema com usuários que queriam trabalhar com esse monte de registros abertos, mas resolvi encaram de frente e mudar essa política. Hoje meus Grids, trazem os 50 ultimos registros, e a tela de pesquisa dá a opção pro cara trazer os registros conforme precisa, mas nesta pesquisa ele pode trazer 1 ou todos os registros... mas aí ele já sabe que se puxar todos os sistema vai ficar mais lento, ou seja transferi essa responsabilidade pra ele. De inicio como trago somente os 50 ultimos em todas as maquinas, o servidor não sobrecarrega nem a rede. Com o tempo o usuário acaba aprendendo a trabalhar com menos registros e nem sente falta dos famigerados (todos registros). Ou seja, a opção está lá, mas ele usa quando quer. Sinceramente, ainda não consegui encontrar uma boa explicação (ou argumento) para se trabalhar com tantos registros assim.
A questão de trazer registros conforme um filtro? Um select resolve isso tranquilamente e você trabalha com dados em tempo real, não corre o risco de informações obsoletas. Outra coisa que estou estudando é trabalhar como o facebook quando carrega os posts, conforme o cara vai chegando proximo dos ultimos registros vou trazendo mais. Mas devemos lembrar que o limite não está somente no servidor e rede, mas na maquina local, pois quando você traz essas informações e não cabe na memoria ele passa a fazer uso da memoria virtual (no disco) ai não tem jeito, fica lento mesmo. Marcelo Silva From: Junior Miranda Sent: Friday, March 13, 2015 1:47 PM To: Comunidade PostgreSQL Brasileira Subject: Re: [pgbr-geral] Consulta lenta Tentei fazer isso, é uma mudança de cultura e não foi bem recebida... outros bancos, como firebird, essa lentidão não é tão acentuada... Alguma sugestão dentro deste cenário?? Júnior Miranda Analista de Sistemas Especializando em Sistemas Computacionais E-mail: flmirandajun...@gmail.com Tel.: (75) 9191-1678/ 34143042/ 34143149/ 34143020 Em 13 de março de 2015 13:43, Vinicius Santos <vinicius.santos.li...@gmail.com> escreveu: Porque não força o usuário a fazer o filtro antes? Abra a tabela depois que tiver o filtro. Em 13 de março de 2015 13:34, Junior Miranda <flmirandajun...@gmail.com> escreveu: O usuário visualiza todos num grid e a partir dai realiza os filtros que desejar. Júnior Miranda Analista de Sistemas Especializando em Sistemas Computacionais E-mail: flmirandajun...@gmail.com Tel.: (75) 9191-1678/ 34143042/ 34143149/ 34143020 Em 13 de março de 2015 13:32, Junior Miranda <flmirandajun...@gmail.com> escreveu: Tenho uma consulta de produtos que possue, no momento, 20 mil registros. Infelizmente para esta consulta eu precisaria retornar todos para que a partir dai o usuário pudesse realizar os seus filtros. Com essa quantidade de registros apresenta uma lentidão na abertura da pesquisa. Não fetch X em X por que nem sem ele consegui retornar os registros. Júnior Miranda Analista de Sistemas Especializando em Sistemas Computacionais E-mail: flmirandajun...@gmail.com Tel.: (75) 9191-1678/ 34143042/ 34143149/ 34143020 Em 13 de março de 2015 13:27, Matheus de Oliveira <matioli.math...@gmail.com> escreveu: 2015-03-13 13:26 GMT-03:00 Junior Miranda <flmirandajun...@gmail.com>: A questão é que inicialmente precisarei retornar todos os registro, e como a tendência é que eles aumentem um pouco, precisaria fazer FETCH de X em X para diminuir o gargalo na abertura. A tendência é que com o aumento essa lentidão aumente... Poucas informações para que possamos ajudar. Você diz pra fazer de X em X, mas você não fez isso. Pode compartilhar conosco o uso de tantos registros assim? Atenciosamente, -- Matheus de Oliveira Analista de Banco de Dados Dextra Sistemas - MPS.Br nível F! www.dextra.com.br/postgres _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral -------------------------------------------------------------------------------- _______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral