Re: Optimizer not using index on 120M row table

Поиск
Список
Период
Сортировка
От Neil Conway
Тема Re: Optimizer not using index on 120M row table
Дата
Msg-id 1049773767.3144.27.camel@tokyo
обсуждение исходный текст
Ответ на Optimizer not using index on 120M row table  ("Jim C. Nasby" <jim@nasby.net>)
Ответы Re: Optimizer not using index on 120M row table  ("Jim C. Nasby" <jim@nasby.net>)
Список pgsql-general
On Mon, 2003-04-07 at 23:29, Jim C. Nasby wrote:
>       Table "public.email_contrib"
>    Column   |     Type      | Modifiers
> ------------+---------------+-----------
>  id         | integer       | not null
>  team_id    | integer       | not null
>  date       | date          | not null
>  project_id | smallint      | not null
>  work_units | numeric(20,0) | not null
> Indexes: email_contrib_pkey primary key btree (project_id, id, date)

>  explain select * from email_contrib where project_id=8 and id=39622 and
> date='3/1/03';

Since project_id is an int2, you need to add single quotes to the
integer literal or cast it to int2 explicitly:

select * from email_contrib where project_id='8' ...

or

select * from email_contrib where project_id=8::int ...

BTW, this is a (well) known bug -- search the archives for more
information.

> On a related note, will pgsql do 'index covering', reading only the
> index if it contains all the information a query needs?

No -- in PostgreSQL, tuple visibility information is only stored in the
heap, not in the index. So the heap tuple always needs to be examined,
to determine if the specified tuple has been updated/deleted by some
transaction.

Cheers,

Neil


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

Предыдущее
От: "Jim C. Nasby"
Дата:
Сообщение: Optimizer not using index on 120M row table
Следующее
От: Tom Lane
Дата:
Сообщение: Re: Optimizer not using index on 120M row table