[SP-pm] Duvida: usar arquivo TXT ou tabela com campo array

Andre Carneiro andregarciacarneiro at gmail.com
Fri Jul 30 05:16:56 PDT 2010


2010/7/30 Renato Santos <renato.cron at gmail.com>

> Bom,
>
> Eu so escutei o papo (são outros desenvolvedores que estão fazendo isso)
> Mas acho que a tabela é esta:
>
>
> A maquina é meio (bastante) lenta, mas nao vão trocar:
> processor    : 0
> vendor_id    : GenuineIntel
> cpu family    : 6
> model        : 8
> model name    : Pentium III (Coppermine)
>

Pentium III ????? Q medo!



>
> Esta query, demorou mais de 500 segundos e nao rodou:
> SELECT esquema, tabela,
>        pg_size_pretty(pg_relation_size(esq_tab)) AS tamanho,
>        pg_size_pretty(pg_total_relation_size(esq_tab)) AS tamanho_total
>   FROM (SELECT tablename AS tabela,
>                schemaname AS esquema,
>                schemaname||'.'||tablename AS esq_tab
>           FROM pg_catalog.pg_tables
>          WHERE schemaname NOT
>             IN ('pg_catalog', 'information_schema', 'pg_toast') ) AS x
>  ORDER BY pg_total_relation_size(esq_tab) DESC;*
>
> *



Humm... cara, vocês precisam melhorar essa query! Nem índice iria ajudar
muito nessa aqui, eu acho...

Ao invés dessa sub-select, você pode testar EXISTS, por exemplo, ou você
pode colocar essa sub-select numa procedure e usar um cursor . Enfim,
pesquise sobre como você pode melhorar essa query( Tunning ), porque apenas
mudar os tipos de dados não vai resolver o seu problema de forma escalável.

http://www.postgresql.org/files/documentation/books/aw_pgsql/node81.html

http://www.postgresql.org/about/press/features84#performance

http://www.developerbay.net/Threads/PostgreSQL/performance-problem-with-correlated-sub-query-63131343.html





Cheers!






*
> Desisto!
>
>
> *Esta rolando um bzip -9 consumindo *possuindo* a maquina neste exato
> momento.
>
>
> Em desenv (que por ironia, é beeem melhor que a producao)
>
> public, mc_corte, 844 MB, 1152 MB
> public, tb_ciclo_inicio, 977 MB, 977 MB
> public, sim_producao, 490 MB, 548 MB
> public, cr_det, 440 MB, 509 MB
> public, sim_mailing, 297 MB, 487 MB
>
>
> A tabela é a tb_ciclo_inicio
>
>
> CREATE TABLE tb_ciclo_inicio
> (
>   cod_cn character(10),
>   ciclo numeric(6,0)
> )
> WITH (
>   OIDS=FALSE
> );
> ALTER TABLE tb_ciclo_inicio OWNER TO natura;
>
>
> O problema é perfomance mesmo.
>
> Hoje tem um perl (eu nao vi ainda) que deve fazer algo assim:
>
> $hash = {};
> foreach (@$rows){
>    $hash->{$_->{cod_cn}}{$_->{ciclo}} = 1
> }
>
> 2010/7/30 Nelson Ferraz <nferraz at gmail.com>
>
>> 2010/7/30 Renato Santos <renato.cron at gmail.com>:
>>
>> > Oi pessoal,
>> >
>> > Eu uso postgres, e hoje, temos uma tabela que guarda todos os meses que
>> uma
>> > pessoa participou do sistema:
>> > Digamos que seja ela assim:
>> > id_pessoa bigint, mes int
>>
>> Duas perguntas:
>>
>> 1) Voce pode nos enviar o esquema (CREATE TABLE) da tabela atual?
>> (Incluindo indices)
>> 2) Quais sao as restricoes que te levaram a considerar a mudanca?
>> (espaco, performance?)
>> _______________________________________________
>> SaoPaulo-pm mailing list
>> SaoPaulo-pm at pm.org
>> http://mail.pm.org/mailman/listinfo/saopaulo-pm
>>
>
>
>
> --
> Renato Santos
> http://www.renatocron.com/blog/
>
> _______________________________________________
> SaoPaulo-pm mailing list
> SaoPaulo-pm at pm.org
> http://mail.pm.org/mailman/listinfo/saopaulo-pm
>



-- 
André Garcia Carneiro
Analista/Desenvolvedor Perl
(11)82907780
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.pm.org/pipermail/saopaulo-pm/attachments/20100730/0a736f53/attachment.html>


More information about the SaoPaulo-pm mailing list