2012/7/25 Vinicius Santos <[email protected]> > >> Com "IN" esse comportamento é bem comum. O IN é bom para um conjunto >> limitado de valores. Por exemplo, produto in (10, 20, 40, 50). Fazer >> IN para "juntar" tabelas não é a melhor opção. >> Tente fazer um join, mais ou menos assim: >> > > Estou utilizando o IN com um conjunto bem limitado de valores. Nos meus > testes estou usando apenas um registro dentro do IN. > Seu passar o valor explicitamente o PostgreSQL utiliza um plano, se eu > passar o mesmo valor, mas através de um SELECT dentro do IN, então o > PostgreSQL utiliza outro plano. >
Cara, cuidado! "Seq scan" não é sinônimo de lentidão. Como o Tiago disse, caso a tabela produtos não seja muito grande (e.g. algumas páginas) é natural que o PostgreSQL escolha um "seq scan" ao invés de um "index scan", já que o "index scan" poderia acarretar mais leituras em disco que um simples "seq scan". Uma forma simples de saber se a tabela é grande ou não para um "index scan" é a consulta abaixo: SELECT relpages FROM pg_class WHERE relname = 'produtos'; Ela te traz a quantidade de páginas usadas para armazenar os dados da tabela. Não é esse o seu caso? A consulta está realmente mais lenta (se comparada à anterior)? No PostgreSQL 9.2 com o "index-only scan", pode ser que o "seq scan" seja menos usado, inclusive nesses casos. Atenciosamente, -- Matheus de Oliveira
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
