Euler, Eu escrevi: > > No meu caso o que sempre fez e continua fazendo uma falta desgraçada no > > Postgres é um otimizador decente (...) Bem que se podia aproveitar a idéia aplicada no > > Oracle ou no SQL Server e ter um cache de planos (...)
> Isso já existe: chama-se comandos preparados (aka _prepared statements_). Isso ??! http://jdbc.postgresql.org/documentation/83/server-prepare.html Não, não estou falando de algo tão simplório. Prepared statements têm diversas desvantagens em relação ao que o Oracle e o SQL Server fazem: * Prepared statements funcionam dentro da mesma conexão. Logo, consultas idênticas feitas por instâncias diferentes da mesma aplicação ou aplicações diferentes que façam as mesmas consultas continuarão tendo um custo alto recompilando dúzias de vezes os mesmos comandos. Isso, é claro, assumindo que eu me dê ao trabalho de mexer na minha aplicação para fazer todas as consultas através da mesma conexão. O ganho disso seria bastante questionável considerando que isso implica em serializar operações que podem correr em paralelo. * Da documentação: "(...) Server side prepared statements are planned only once by the server. This avoids the cost of replanning the query every time, but also means that the planner cannot take advantage of the particular parameter values used in a particular execution of the query. (...)" Logo, Prepared statements usam o mesmo plano independente dos valores, o que resulta em desastre. Isso é exatamente o *oposto* do que se espera de um otimizador decente. O otimizador deveria ter uma lista de planos para a mesma consulta e usar o mais adequado para cada uma. > É claro que você precisa manter a conexão mas nada que um aglomerador de > conexões (aka _pool_) não resolva. Como expus acima, fazer isso, ainda por cima em larga escala, resulta em desastre. > Como você mesmo disse, o tempo é relativamente pequeno em aplicações Web e > OLTP; em OLAP, algumas consultas com dezenas de junções esse tempo é > significativo (aumenta 2^n mas é para isso que temos o GEQO) mas mesmo assim > bem inferior ao de execução da consulta. Dezenas de junções não são exclusividade de aplicações OLAP, muito pelo contrário. O fato de uma consulta cheia de junções exigir um enorme tempo de planejamento de forma alguma implica em não valer a pena gastá-lo fazendo isso. É exatamente nessas tabelas potencialmente grandes e cheias de índices que uma escolha errada do otimizador resulta em planos catastróficos. > É fácil falar do otimizador mas é difícil mexer nele. ;) Ora, ora, pelo menos nisso concordamos integralmente. A pergunta do tópico foi quanto ao que se poderia melhorar em desempenho, só estou expondo a lista para resolver os *meus* problemas. Afinal, custa-me acreditar que sou o único interessado em desempenho por aqui. > Já tivemos essa discussão a um tempo atrás (...). Se eu me lembro bem, nenhuma das > consultas apresentadas por você produzia um plano que não era ideal. Depende do que chamarmos de "ideal". Para mim o ideal é medir as consultas em milissegundos para poder comparar com Oracle e SQL Server, e não em minutos. OK, de fato não tenho no momento exemplos usando a última versão do Postgres, quando tiver passo para a lista. Fazer testes comparativos de desempenho é algo que consome tempo que é dificílimo de conseguir considerando nossas experiências anteriores. Atenciosamente, Mozart Hasse _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
