Fala pessoal... Leandro, Gostei da sua solução mas acho que cabem algumas considerações: 1 - Com isso estaremos criando uma redundância dos dados - a informação da nova coluna pode ser extraída da coluna já existente; 2 - Para cada intervalo será necessário reprocessar a coluna ou criar uma coluna para o respectivo intervalo; 3 - Apesar de não ter feito um EXPLAIN na consulta que eu propus creio que seria mais eficiente do que ter que reprocessar uma coluna inteira (de uma massa possivelmente grande - dados inseridos a cada 10s) ou ainda criar uma tabela temporária; 4 - Com a consulta proposta é possível fazer uma função que receba a precisão e o case no select poderia ser substituido/alterados de modo a representar um intervalo de tempo válido na respectiva precisão;
Mas cabe agora ao Newton avaliar as duas soluções e ver a que melhor se aplica à realidade dele. Com uma tabela auxiliar, alguns relatórios poderiam ter um melhor desempenho, dependendo do caso, ou ainda poderia ser usada para outras coisas... as variáveis são muitas. Bom, é isso... Espero ter dado minha contribuição neste problema. 2010/1/16 Leandro Cavalari Soares <[email protected]>: > Bom dia Newton! > Vejo uma maneira genérica de se obter este relatório, mas precisará de uma > coluna auxiliar e um ajuste nos dados antes de cada execução. Minha sugestão > é a seguinte: > > Criar uma coluna bh_dthr_piso que armazenará o maior valor de data, múltiplo > do intervalo requisitado e menor que bh_dthr; > Executar uma função antes do relatório que atualize a > coluna bh_dthr_piso com o devido valor (como mostrado em [A] para um > intervalo de 3 minutos); > Neste ponto seus dados estarão agrupados dentro do intervalo requisitado, > bastando executar seu SELECT agrupado por bh_dthr_piso e não mais > necessitando dos EXTRACTS. > > [A] > bh_dthr; bh_dthr_piso;valor > "2010-01-08 20:00:20-03";"2010-01-08 20:00:00-03";77.477 > "2010-01-08 20:01:10-03";"2010-01-08 20:00:00-03";81.0406 > "2010-01-08 20:01:50-03";"2010-01-08 20:00:00-03";78.1369 > "2010-01-08 20:02:20-03";"2010-01-08 20:00:00-03";77.8729 > "2010-01-08 20:03:20-03";"2010-01-08 20:03:00-03";76.685 > "2010-01-08 20:03:50-03";"2010-01-08 20:03:00-03";73.6493 > "2010-01-08 20:04:20-03";"2010-01-08 20:03:00-03";76.0251 > "2010-01-08 20:05:00-03";"2010-01-08 20:03:00-03";75.2332 > "2010-01-08 20:05:40-03";"2010-01-08 20:03:00-03";71.0095 > "2010-01-08 20:06:20-03";"2010-01-08 20:06:00-03";74.9692 > "2010-01-08 20:06:50-03";"2010-01-08 20:06:00-03";73.1214 > "2010-01-08 20:07:30-03";"2010-01-08 20:06:00-03";73.5173 > "2010-01-08 20:08:00-03";"2010-01-08 20:06:00-03";74.9692 > "2010-01-08 20:08:30-03";"2010-01-08 20:06:00-03";75.3652 > "2010-01-08 20:09:00-03";"2010-01-08 20:09:00-03";74.4412 > Apesar de ser genérica esta solução pode ser pesada dependendo da massa de > dados e/ou hardware. Caso não precise do relatório sobre toda a massa de > dados, mas sim de um subconjunto dela, pense na possibilidade de gerar uma > tabela temporária com tais valores ao invés de ficar atualizando sua tabela > original. > Espero ter ajudado. > -- > Leandro Cavalari Soares > Analista de Sistemas / DBA > Veltrac - Tecnologia em Logística > (43) 2105-5614 / (43) 9922-8095 - Londrina / PR > > _______________________________________________ > 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
