Desde já agradeço a ajuda e comentários de todos.

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.


--Os indices foram necessários e criados a medida que foi sendo
desenvolvido a aplicação e observando a necessidade.

--ao executar "SELECT * FROM televenda_pedidos.vpedidonpago LIMIT
100", demora muito para retornar qualquer resultado isso quando
retorna

explain SELECT * FROM televenda_pedidos.vpedidonpago

Nested Loop  (cost=154915.82..3521827763.32 rows=5285 width=56)

  ->  HashAggregate  (cost=119441.06..120504.41 rows=85068 width=8)

        ->  Hash Join  (cost=42950.90..114544.82 rows=979248 width=8)

              Hash Cond: ("outer".codpedido = "inner".codpedido)

              ->  Seq Scan on receber  (cost=0.00..31467.72
rows=1432772 width=8)

              ->  Hash  (cost=39906.13..39906.13 rows=412308 width=4)

                    ->  Bitmap Heap Scan on pedido
(cost=2609.69..39906.13 rows=412308 width=4)

                          Recheck Cond: ((status = 4) OR (status = 44)
OR (status = 59))

                          ->  BitmapOr  (cost=2609.69..2609.69
rows=416768 width=0)

                                ->  Bitmap Index Scan on
idx_pedido_status  (cost=0.00..2564.76 rows=410218 width=0)

                                      Index Cond: (status = 4)

                                ->  Bitmap Index Scan on
idx_pedido_status  (cost=0.00..22.46 rows=3275 width=0)

                                      Index Cond: (status = 44)

                                ->  Bitmap Index Scan on
idx_pedido_status  (cost=0.00..22.46 rows=3275 width=0)

                                      Index Cond: (status = 59)

  ->  Index Scan using un_codpedido_rec_parcela on receber
(cost=35474.76..41398.71 rows=1 width=60)

        Index Cond: (("outer".codpedido = receber.codpedido) AND
("outer"."?column2?" = receber.rec_parcela))

        Filter: ((valorpago IS NULL) OR (subplan))

        SubPlan

          ->  Materialize  (cost=35474.76..45611.20 rows=681044 width=4)

                ->  Seq Scan on receber  (cost=0.00..31467.72
rows=681044 width=4)

                      Filter: (datapag IS NULL)
                                        
                                        
                                        

--Quando executo as consultas sem o uso de VIEW ou SUBCONSULTAS elas
retornam dados rapidamente.

--view para pegar ultima parcela e conferir se está paga, somente foi
adaptada do mssql
CREATE VIEW televenda_pedidos.vUltimaParcela AS
SELECT receber.codpedido, max(receber.rec_parcela) AS max_rec_parcela
FROM televenda_pedidos.receber JOIN televenda_pedidos.pedido ON
pedido.codpedido = receber.codpedido WHERE pedido.status = 4 OR
pedido.status = 44 OR pedido.status = 59 GROUP BY receber.codpedido;

--view com os pedidos não pagos, preciso por causa da repetição de
dados se não usar view ou subconsultas!!!!!
CREATE VIEW televenda_pedidos.vpedidonpago AS
 SELECT receber.codpedido, receber.datavencent, receber.valorparcela,
receber.numcobraut, receber.datapag, receber.valorpago
   FROM vultimaparcela
   JOIN receber ON vultimaparcela.max_rec_parcela =
receber.rec_parcela AND vultimaparcela.codpedido = receber.codpedido
  WHERE receber.valorpago IS NULL OR (receber.codpedido IN ( SELECT
receber.codpedido
      FROM receber
     WHERE receber.datapag IS NULL));

        
CREATE TABLE pedido ( --atualmente com  603262 registros
    codpedido serial NOT NULL,
    codcliente integer,
    atendente character varying(20),
    datahora timestamp without time zone DEFAULT now() NOT NULL,
    solicitante character varying(60),
    setor character varying(60),
    codfconhece integer NOT NULL,
    codfpedido integer NOT NULL,
    codfenvio integer,
    codfpag integer,
    valor numeric(13,2),
    despesa numeric(13,2) DEFAULT 0 NOT NULL,
    desconto numeric(13,2) DEFAULT 0 NOT NULL,
    acrescimo numeric(13,2) DEFAULT 0 NOT NULL,
    total numeric(13,2) DEFAULT 0 NOT NULL,
    prevenvio timestamp without time zone,
    dataenvio timestamp without time zone,
    numenvio character varying(20),
    dtagenda timestamp without time zone,
    valorpago character varying(30),
    obs character varying(255),
    status integer DEFAULT 1 NOT NULL,
);

ALTER TABLE ONLY pedido ADD CONSTRAINT pedido_pkey PRIMARY KEY (codpedido);

CREATE INDEX idx_pedido_cliente ON pedido USING btree (codcliente);

CREATE INDEX idx_pedido_datahora ON pedido USING btree (datahora);

CREATE INDEX idx_pedido_status ON pedido USING btree (status);


CREATE TABLE receber ( --atualmente com 1432772
    codpedido integer NOT NULL,
    datavencent timestamp without time zone NOT NULL,
    valorparcela numeric(13,2),
    numcobraut character varying(20),
    datapag timestamp without time zone,
    valorpago numeric(13,2),
    rec_parcela integer DEFAULT 1 NOT NULL,
    rec_id serial NOT NULL,
);

ALTER TABLE ONLY receber ADD CONSTRAINT receber_pkey PRIMARY KEY (rec_id);

ALTER TABLE ONLY receber ADD CONSTRAINT un_codpedido_rec_parcela
UNIQUE (codpedido, rec_parcela);

CREATE INDEX idx_receber_codpedido ON receber USING btree (codpedido);

CREATE INDEX idx_receber_datapag ON receber USING btree (datapag);

CREATE INDEX idx_receber_datavencent ON receber USING btree (datavencent);

CREATE INDEX idx_receber_rec_parcela ON receber USING btree (rec_parcela);




2008/8/20 André Volpato <[EMAIL PROTECTED]>:
> José Carlos Messias escreveu:
>> Estou achando que seja alguma configuração do servidor postgresql 8.1,
>> vou passar
>> para vocês darem uma olhada ou tem algum bug relacionado com esta
>> versão do postgresql?
>>
>>
>
> Use a última versão do 8.1 (8.1.13), ou de preferência a última versão
> estável (8.3.3).

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.

>
>> 2 Processadores Intel(R) Xeon(R) CPU E5320  @ 1.86GHz
>> 4GB de RAM
>> 3 HD's SAS de 73GB em RAID 5
>>
>
> RAID5 com 3 hds não é uma conf muito aconselhável. Não sei quais são as
> tuas necessidades, mas você teria um ganho bom com mais um HD.
> Melhor ainda se for RAID10...
>
>> S.O. Debian GNU/Linux 4.0
>>
>> port = 5432
>> 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.

>> 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á...

Vou ajustar para esta configuraçao e reporto depois.

>
>> max_fsm_pages = 40000
>> max_fsm_relations = 2100
>>
>
> Não esqueça de mandar os explain analyze, como pediram. E verifique se
> as colunas joinadas possuem índice.
>

Segue no inicio do email.

> --
>
> ACV
>
>
> _______________________________________________
> 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

Responder a