Pela teoria, acredito que converter o valor 2006 em 'text' possa ser mais lento que deixá-lo como um tipo numérico. Mas como você está usando esta comparação fora de uma condição (WHERE) de consulta SQL, acredito que a diferença seja imperceptível.
Se você está comparando colunas e valores em uma cláusula SQL, tudo depende de como os seus índices estão projetados e da quantidade de registros na tabela. Eu já fiz alguns testes na base de dados que possuímos em nosso ERP, seguindo o preceito filosófico e teórico de que indexação sobre campos numéricos é mais rápida que em campos texto. Com esta premissa, testei o tempo de recuperação em campos texto fixos (CHARACTER, não VARCHAR) com tamanho 8, e foram muito mais rápidos (cerca de 40% na época) do que os campos do tipo INTEGER, e - pasmem - mais rápido que um campo do tipo NUMERIC(8,0). -- Tiago J. Adami Dois Vizinhos - Paraná - Brasil 2009/7/26 sergio nogueira <[email protected]> > Eu tinha posto '2006'::text porque executando um explain com a consulta vi > que havia uma comparação entre um double e um text. Por falta de atenção e > não ter me atentado no manual, conclui rapidamente que o double era o > '2006', quando era o ano em date_part. Na verdade me pareceu mais lógico, já > que date_part('year ..) seria um valor conhecido : ou texto, ou smallint ou > int, nunca um double (porque um double para ano?). Então, para confirmar: > qualquer coisa entre plics é sempre um texto? > O que é mais rápido, a comparação entre textos ou entre doubles? > > Att., > Sergio > > 2009/7/26 Tiago Adami <[email protected]> > > Olá, Roberto. >> >> A partir da versão 8.3 do PostgreSQL, não existe mais CAST automático. Não >> entendi direito se esta mudança foi para deixá-lo mais parecido com o Oracle >> ou para deixá-lo mais adequado ao SQL ANSI. Acredito que a maioria já >> percebeu isso - ou seja, não vai ser "bem assim" migrar bases de dados >> existentes de versões anteriores para a 8.3. >> >> De uma forma ou de outra, esta mudança veio para mostrar a mim e a muitos >> programadores em SQL e Pl/PgSQL os seus erros. O certo seria existir estes >> Casts desde o início, infelizmente. >> >> >> -- >> Tiago Adami >> Paraná - Brasil >> >> >> 2009/7/25 sergio nogueira <[email protected]> >> >> Roberto, >>> era burrice minha mesmo. A função controla a inserção de dados numa >>> tabela particionada por ano (2007 a 2010) e eu estava tentando inserir dados >>> de 2006 (a tabela não existia, claro). Então nenhuma instrução chegava a ser >>> formada, na função. Logo, nada havia a ser exibido. Quando a função era >>> chamado nos inserts, com dados de 2006, ia direto para o RAISE EXCEPTION e >>> exibia a MINHA MENSAGEM, que não esclarecia nada. Corrigi a minha mensagem >>> de erro. >>> Um outro problema (outra burrice) que tive foi ao restaurar um dump de um >>> PstgreSQL 8.2 para um 8.4 (meu notebook, para testes). >>> >>> A função testa com >>> IF ( date_part('year', NEW.data::timestamp) = '2006'::text ) THEN >>> ... >>> ELSEIF ... >>> ... >>> ELSE RAISE EXCEPTION .... >>> >>> Funciona no 8.2 e eu achava que estava ajudando o analisador com os >>> casts. >>> Resultado no 8.4: >>> >>> ERRO: operador n�o existe: double precision = text no caracter 46 >>> DICA: Nenhum operador corresponde com o nome e o(s) tipo(s) de >>> argumento(s) informados. Voc� precisa adicionar >>> convers�es de tipo expl�citas. >>> -- >>> ERRO: operador n�o existe: double precision = text >>> LINHA 1: SELECT ( date_part('year', $1 ::timestamp) = '2006'::text >>> ... >>> >>> Alterei para >>> IF ( date_part('year', NEW.data::timestamp)::text = '2006'::text ) THEN >>> >>> e agora funciona no 8.4 >>> >>> Você sugeriria algo melhor, para estes casts? >>> >>> Att., >>> Sergio >>> >>> >>> 2009/7/13 Roberto Mello <[email protected]> >>> >>>> 2009/7/12 sergio nogueira <[email protected]> >>>> >>>>> Sr(a)s, >>>>> como faço para que numa função, raise notice exiba o comando sql que >>>>> disparou o aviso? >>>>> >>>> >>>> A função usa PL/pgSQL, não SQL. Como você tem controle da função, por >>>> que não colocar o aviso antes dos seu RAISE NOTICE? >>>> >>>> Ou eu não estou entendendo o que você está tentando fazer. >>>> >>>> Roberto >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >>> >> >> >> >> _______________________________________________ >> 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 > >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
