Re: Indexes not used in 7.1RC4: Bug?

Поиск
Список
Период
Сортировка
От Thomas Lockhart
Тема Re: Indexes not used in 7.1RC4: Bug?
Дата
Msg-id 3AD3105E.E4AC682@alumni.caltech.edu
обсуждение исходный текст
Ответ на Indexes not used in 7.1RC4: Bug?  (Alvar Freude <alvar@agi.de>)
Ответы Speaking of Indexing... (Text indexing)  (Poet/Joshua Drake <poet@linuxports.com>)
Список pgsql-hackers
> I have the following table, containing about 570000 Rows, but some
> indexes are not used, on 7.1RC4, freshly vacuumed (analyse). It was the
> same at least in 7.1RC1
>       CREATE TABLE access_log(
>          access_time timestamp   NOT NULL DEFAULT NOW(),
>          method_num  int2        NOT NULL,
>          url_id      int4        NOT NULL REFERENCES urls(id),
>          );
>       CREATE INDEX method_idx       ON access_log(method_num);
>       CREATE INDEX url_idx          ON access_log(url_id);
> url_idx seems OK:
> But the others not:
>   logger=# EXPLAIN SELECT * FROM access_log WHERE method_num = 0;
>   Seq Scan on access_log  (cost=0.00..16443.71 rows=559371 width=89)

The parser does not know that your int4 constant "0" can be represented
as an int2. Try

  SELECT * FROM access_log WHERE method_num = int2 '0';

(note the type coersion on the constant; there are other ways of
specifying the same thing).

For the other cases, PostgreSQL is estimating the query cost to be lower
with a sequential scan. For the "SELECT 1" subselect case, it may be
that the optimizer does not cheat and determine that there will be only
one row returned, or that the query can be reformulated to use a simple
constant.

HTH

                     - Thomas

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Peter Mount
Дата:
Сообщение: Large Object problems (was Re: JDBC int8 hack)
Следующее
От: Bruce Momjian
Дата:
Сообщение: Re: Re: "--tuning" compile and runtime option (?)