"Aggregate (cost=21.88..21.97 rows=1 width=42) (actual time=0.734..0.734
rows=1 loops=1)"
" -> Nested Loop Left Join (cost=0.00..21.80 rows=1 width=42) (actual
time=0.057..0.453 rows=25 loops=1)"
" -> Nested Loop Left Join (cost=0.00..19.52 rows=1 width=41)
(actual time=0.051..0.329 rows=25 loops=1)"
" Filter: ("NotaFiscal"."CodigoNotaMatrizNota" IS NULL)"
*O filter acima, é destinado a um campo do inteiro e que tem índice mas o
planejador não consegue usar*
" -> Index Scan using
"NotaItem_Empresa_Produto_Data_Situacao_I" on "NotaItem" (cost=0.00..10.89
rows=1 width=41) (actual time=0.038..0.095 rows=25 loops=1)"
" Index Cond: (("CodigoEmpresaItem" = 77222) AND
("CodigoProdutoItem" = 27149) AND ("DataMovimentoItem" >=
'2013-12-01'::date) AND ("DataMovimentoItem" <= '2013-12-31'::date))"
" Filter: ("SituacaoNotaItem" IS NULL)"
*O filter acima, é destinado a um campo do varchar(1) e que tem índice mas
o planejador não consegue usar*
" -> Index Scan using "NotaFiscal_CodigoInterno_PK" on
"NotaFiscal" (cost=0.00..8.62 rows=1 width=12) (actual time=0.005..0.006
rows=1 loops=25)"
" Index Cond: ("NotaItem"."CodigoNotaItem" =
"NotaFiscal"."CodigoInternoNota")"
" -> Index Scan using "Operacao_CodigoInterno_PK" on "Operacao"
(cost=0.00..2.27 rows=1 width=9) (actual time=0.002..0.003 rows=1
loops=25)"
" Index Cond: ("NotaFiscal"."CodigoOperacaoEstoqueNota" =
"Operacao"."CodigoInternoOperacoes")"
"Total runtime: 1.053 ms"
O tempo não é ruim mas da para ser melhor!
Um detalhe importante que esqueci de falar, é que a versão do banco que uso
é 8.2.23. Estamos com planos para mudar para a mais nova versão, ma
dependemos que componentes de terceiros para a nossa linguagem ajustem seus
processos também para a nova versão. Na verdade, estamos presos a espera
dos outros!!!
Marcos André G.A
Trabin Softwarre & Consulting - www.trabin.com.br
*Blog:* http://lgerardlucas.blogspot.com/
*twitter:* http://twitter.com/lgerardlucas
Em 30 de janeiro de 2014 20:42, Matheus de Oliveira <
[email protected]> escreveu:
>
> 2014-01-30 Marcos - GMail <[email protected]>
>
>> Pessoal, uma vez assisti algumas palestras de postgresql e em uma delas,
>> alguém falou sobre a possibilidade de alterar o parâmetro work_mem por
>> sessão. Por exemplo: 40 usuários requisitando diversos relatórios dos quais
>> todos tem ordenação.
>>
>
> Verifique a possibilidade de criação de índices que casam com o "ORDER
> BY", muitas vezes evitará por completo a necessidade de uso de memória ou
> disco para ordenação, o próprio índice trará os dados já ordenados. Se
> quiser, envie-nos o EXPLAIN ANALYZE dessas consultas que podemos ajudar com
> dicas de bons índices ou configurações adequadas.
>
>
>
>> Nestas consultas, considerando que todas foram feitas em plpgsql, na
>> primeira linha das mesmas, eu teria o comando *set work_mem = '15MB'; *
>>
>>
> Em funções PL/pgSQL, é fácil:
>
> CREATE OR REPLACE FUNCTION public.dah()
> ....
> * SET work_mem TO '15MB'*
> AS $$
> ...
> $$;
>
>
>
>> *É uma boa práticas? *
>>
>>
> Bem, isso vai depender o quanto de memória disponível que seu servidor
> possuirá. Pode ser até possível já manter 15MB para todos (o padrão, 1MB, é
> bem conservativo).
>
> A conta geral é que seria usado até (work_mem * max_connections) de
> memória para ordeanação/bitmap/etc. A realidade é que pode ser mais do que
> isso, mas essa é uma boa estimativa (já que muitas sessões vão usar menos).
>
> 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
> [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
