Se entendi direito, nesse seu caso especifico não há necessidade de fazer separado, pois o que você quer é o "total geral" para cada registro e isso pode ser resolvido sem um subselect, fazendo uma união com o resultado de um select, conforme exemplo abaixo:

select codigo, teste.total from cliente inner join (select count(*) as total from cliente) as teste on true;

Wagner Bonfiglio escreveu:
Todas opiniões muito boas, e os "E se" do Dickson mostram que tem várias questões que podem levar pra cada um dos pontos...

Eu estou otimizando algumas consultas aqui de outros sistemas já prontos e peguei uma que é um exemplo do que pode acontecer quando se opta por uma consulta com todos os resultados...

É mais ou menos isso:

select
  (select count(*) from A,B,C where A.x=B.y and C.z=B.w and .. and ... and ...) as total,
  x,
  y,
  z,
  w
from A,B,C
where A.x=B.y and C.z=B.w and .. and ... and ...
limit 2

Só para retornar o número que seria total de registros sem o LIMIT, acaba-se fazendo uma subquery exatamente igual a quey, mas retornando o count(*) sem limit...

Então no começo de cada linha tem o numero N total de linhas da consulta


Deu pra entender o drama? hauehueaeh


2009/5/25 Dickson S. Guedes <lis...@guedesoft.net>
Em Seg, 2009-05-25 às 11:47 -0300, Wagner Bonfiglio escreveu:
(...)
> Ele disse que prefere fazer uma consulta mais pesada mas que retorne o
> máximo de dados possíveis de uma só vez, para que o tratamento seja
> feito dentro do código e assim evitar o excesso de conexões ao
> banco...
(...)
> Vocês tem alguma opinião formada sobre isso? Ou melhor, existe alguma
> verdade absoluta sobre melhor prática nesse sentido?

E se 100 usuários simultâneos dispararem o mesmo evento no sistema que
execute esta consulta?

E se dessa consulta apenas 20% dos registros forem realmente os
necessários?

E se leva mais tempo para o banco planejar, executar e devolver os
resultados desta consulta do que de várias consultas menores somadas,
ainda vale à pena?

E se o problema é evitar muitas conexões/desconexões com o banco, porque
não utilizar um aglomerador de conexões como pgbouncer ou pgpoolII?


Wagner, sua colocação é bem pertinente, e realmente os vários "e se ..."
acima são apenas algumas das questões que você tem que fazer para si e
para os seus desenvolvedores.

Vamos ver o que os demais colegas podem contribuir com suas
experiências.


Um abraço.
Dickson S. Guedes
mail/xmpp: gue...@guedesoft.net - skype: guediz
http://guedesoft.net - http://www.postgresql.org.br
http://www.rnp.br/keyserver/pks/lookup?search=0x8F3E3C06D428D10A

_______________________________________________
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


-- 
                                                                       Danilo Pacheco Martins
                                                                       InfoCont Sistemas Integrados Ltda.
                                                                       Diretor    
                                                                       Fone: (47) 3422-3536


_______________________________________________
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Reply via email to