Peço desculpas pelo toppost foi devido ao desespero de não conseguir
fazer a migração, mas após colocar o work_mem com 128MB, consegui ter
resultados com aproximadamente 7 a 12seg, troquei o work_men para 32MB
conforme indicado pelo Euler.
Quanto a aplicação em PHP 5 + Apache 2, SIM estou usando conexões
persistentes com ADODB. Alguma dica?
Segue o explain analyze:
Merge Join (cost=362542.47..371151.94 rows=5283 width=56) (actual
time=12785.255..13765.140 rows=35156 loops=1)
Merge Cond: (("outer".codpedido = "inner".codpedido) AND
("outer".max_rec_parcela = "inner".rec_parcela))
-> Sort (cost=128183.18..128393.72 rows=84216 width=8) (actual
time=6343.411..6573.183 rows=417727 loops=1)
Sort Key: vultimaparcela.codpedido, vultimaparcela.max_rec_parcela
-> Subquery Scan vultimaparcela (cost=119398.69..121293.55
rows=84216 width=8) (actual time=4130.442..4482.184 rows=417727
loops=1)
-> HashAggregate (cost=119398.69..120451.39
rows=84216 width=8) (actual time=4130.439..4335.600 rows=417727
loops=1)
-> Hash Join (cost=42915.52..114504.45
rows=978849 width=8) (actual time=715.043..3507.827 rows=868669
loops=1)
Hash Cond: ("outer".codpedido = "inner".codpedido)
-> Seq Scan on receber
(cost=0.00..31467.72 rows=1432772 width=8) (actual time=0.006..608.925
rows=1432772 loops=1)
-> Hash (cost=39872.17..39872.17
rows=412140 width=4) (actual time=714.353..714.353 rows=417743
loops=1)
-> Bitmap Heap Scan on pedido
(cost=2599.86..39872.17 rows=412140 width=4) (actual
time=85.631..419.278 rows=417743 loops=1)
Recheck Cond: ((status = 4) OR
(status = 44) OR (status = 59))
-> BitmapOr
(cost=2599.86..2599.86 rows=415389 width=0) (actual
time=76.816..76.816 rows=0 loops=1)
-> Bitmap Index Scan on
idx_pedido_status (cost=0.00..2567.17 rows=410620 width=0) (actual
time=75.774..75.774 rows=411960 loops=1)
Index Cond: (status = 4)
-> Bitmap Index Scan on
idx_pedido_status (cost=0.00..16.35 rows=2384 width=0) (actual
time=0.667..0.667 rows=3527 loops=1)
Index Cond: (status = 44)
-> Bitmap Index Scan on
idx_pedido_status (cost=0.00..16.35 rows=2384 width=0) (actual
time=0.372..0.372 rows=2256 loops=1)
Index Cond: (status = 59)
-> Sort (cost=234359.29..237000.96 rows=1056669 width=60) (actual
time=6441.787..6822.392 rows=725632 loops=1)
Sort Key: receber.codpedido, receber.rec_parcela
-> Seq Scan on receber (cost=33169.14..68218.79
rows=1056669 width=60) (actual time=895.653..1736.971 rows=729363
loops=1)
Filter: ((valorpago IS NULL) OR (hashed subplan))
SubPlan
-> Seq Scan on receber (cost=0.00..31467.72
rows=680567 width=4) (actual time=0.036..562.784 rows=682250 loops=1)
Filter: (datapag IS NULL)
2008/8/20 Euler Taveira de Oliveira <[EMAIL PROTECTED]>:
> José Carlos Messias escreveu:
>> Como solicitado achei melhor colocar no site devido a formatação um
>> arquivo txt no link http://www.cpt.com.br/zehk/sql.txt, mas segue no
>> corpo do email também. Veja mais comentarios nas entrelinhas sobre as
>> configurações do servidor abaixo.
>>
> Na verdade seria o EXPLAIN *ANALYZE* e não somente o EXPLAIN. Seria bom
> ver as duas consultas: (i) utilizando visões (ii) utilizando somente
> tabelas.
> Como um colega já alertou, o parâmetro work_mem está muito baixo mas
> talvez não seja o caso de aumentá-lo para todo o agrupamento de banco de
> dados. Experimente o *set work_mem to '32MB'*, que altera esse parâmetro
> somente naquela sessão. Experimente vários valores e veja se o plano de
> execução é alterado.
>
>>
>> 2008/8/20 André Volpato <[EMAIL PROTECTED]>:
>>> José Carlos Messias escreveu:
>
>> Como é um servidor estável em produção estou usando a versão fornecida
>> via APT-GET do debian "postgresql-8.1 8.1.11-0etch1",
>>
>> Fiz algumas tentativas de migrar para 8.3.3 mas barrei na codificação.
>>
> Não entendi. Qual o problema com a codificação?
>
>>>> max_connections = 700
>>>>
>>> Precisa mesmo de tantas conexões?
>>
>> Fui aumentando para evitar erros de número máximo de conexões
>> atingidas, utilizamos apache 2+php 5 em nosso sistema.
>>
> Sugiro rever porque a aplicação está consumindo tantas conexões. Você
> está utilizando conexões persistentes?
>
>>>> shared_buffers = 80000
>>>> work_mem = 8192
>>>>
>>> Parece pouco. Este fator está ligado diretamente com as ordenações.
>>> Tente aumentar para uns 128MB e vê no qe dá...
>>
> *Não* faça isso. Esse parâmetro é por sessão. Assim, com _apenas_ 32
> conexões você ocupará os 4GB! Veja dica acima.
>
> PS> pessoal, evitem *top-postings* [1]. Fica difícil descobrir quem
> escreveu o que! Vide regras da lista [2] e um texto interessante sobre o
> assunto [3].
>
>
> [1] http://en.wikipedia.org/wiki/Posting_style
> [2] http://www.postgresql.org.br/RegrasLista
> [3] http://www.caliburn.nl/topposting.html
>
>
> --
> Euler Taveira de Oliveira
> http://www.timbira.com/
> _______________________________________________
> 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
