William Leite Araújo wrote:
> # select version();
> version
> ----------------------------------------------------------------------------------------
> PostgreSQL 8.3.1 on i486-pc-linux-gnu, compiled by GCC cc (GCC) 4.2.3
> (Debian 4.2.3-2)
>
> #select 1 from xmls_logs where xml_id = '534'::numeric;
> ?column?
> ----------
> 1
> (1 registro)
>
> Tempo: 34,068 ms
> mobile_card=# select 1 from xmls_logs where xml_id = '534';
> ?column?
> ----------
> 1
> (1 registro)
>
> Tempo: 1,475 ms
>
> * Bom, vamos mudar a ordem então:*
>
> #select 1 from xmls_logs where xml_id = '534';
> ?column?
> ----------
> 1
> (1 registro)
>
> *Tempo: 4,725 ms*
> # select 1 from xmls_logs where xml_id = '534'::numeric;
> ?column?
> ----------
> 1
> (1 registro)
>
> *Tempo: 35,339 ms*
>
> Ok. Provavelmente meu servidor não possui otimizações. Mas é para
> teste. É para não ter otimizações mesmo. Confesso que, para que o tempo
> caísse tanto, aumentei a memória compartinhada e redizí as conexões
> simultâneas. Mas o que estou tentando mostrar é o que está na documentação.
>
> Tabela "public.xmls_logs"
> Coluna | Tipo |
> Modificadores
> ------------------+------------------------+------------------------------------------------------------
> xml_id | integer | not null default
> nextval('xmls_logs_xml_id_seq'::regclass)
> xml_xml_in | text | not null
> xml_xml_out | text |
> xml_dsc_tabel | character varying(256) |
> xml_int_tabel_id | integer |
> xml_dat_tstam | date | not null default
> ('now'::text)::date
> xml_tim_tstam | time without time zone | not null default
> (now())::time without time zone
> Índices:
> "pk_xmls_logs" PRIMARY KEY, btree (xml_id)
Meu amigo, eu fiz aquilo tudo em meu desktop ubuntu com opções padrão
do postgresql.
Mas agora que mandou a estrutura, o erro está claro, o problema não é
do tipo numeric.
Você tem um campo em sua tabela com o tipo integer, quando você usa
"select 1 from xmls_logs where xml_id = '534';" o postgresql consegue
fazer o casting de string para inteiro e utilizar o índice (somente a
partir da versão 8.0), mas... o postgresql não faz casting automático
de tipo numeric para inteiro (ainda bem que não faz) pois você perderia
precisão dos dados, logo sua segunda consulta não utiliza o índice e por
este motivo demora mais.
Faça o explain das duas consultas que verá que uma vai utilizar o
indice pk_xmls_logs e a segunda não.
Como eu falei antes o erro é de modelagem e não do postGreSql, pois
este trabalha muito bem com tipos numeric, mas ele não faz autocasting
de numeric para integer, nem adivinha intenções obscuras.
ps: Por este motivo eu havia dito para não dar informações categóricas
daquela forma na lista, existem usuários de PostGreSql de níveis bem
diferentes por aqui, uns começando agora, outros já calejados. Espero
que tenha ficado claro, PostGreSql não tem problemas com campos do tipo
numeric, não perde performance na utilização deles. Se ainda restar
alguma dúvida, icq: 71366121
Abraço e boa sorte,
--
Shander Lyrio
_______________________________________________
pgbr-geral mailing list
[email protected]
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
