Re: Avoiding a seq scan on a table.

Поиск
Список
Период
Сортировка
От LWATCDR
Тема Re: Avoiding a seq scan on a table.
Дата
Msg-id 8c38cea40801140845n2f52babft789d5f7cc2140ffc@mail.gmail.com
обсуждение исходный текст
Ответ на Avoiding a seq scan on a table.  (LWATCDR <lwatcdr@gmail.com>)
Ответы Re: Avoiding a seq scan on a table.  ("Sean Davis" <sdavis2@mail.nih.gov>)
Re: Avoiding a seq scan on a table.  (Brian Hurt <bhurt@janestcapital.com>)
Список pgsql-novice
Thanks would you suggest a btree or a hash? My guess would a hash
since it uses an =.

On Jan 14, 2008 11:41 AM, Brian Hurt <bhurt@janestcapital.com> wrote:
>
> LWATCDR wrote:
>
> >I am trying to create and index that will prevent a seq scan table.
> >The querey that is causing the seq scan is this SELECT COUNT(*) FROM
> >issuetracking where (issue_target='david' OR manager='david') AND
> >date_closed=null;
> >Any ideas on what
> >Any suggestions on what index I can add that will make this not a seq scan?
> >
> >---------------------------(end of broadcast)---------------------------
> >TIP 5: don't forget to increase your free space map settings
> >
> >
> >
> >
> I would recommend making three indexes- one on issue_target, one on
> manager, and one on date_closed.  Postgres can then do a trick where it
> turns the indexes into bitscan indexes (with one "bit" per page as to
> wether that page might have a row of interest or not), which it can then
> bitwise and and or combine together.
>
> Don't forget to analyze the table after making the indexes.
>
> Brian
>
>

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

Предыдущее
От: LWATCDR
Дата:
Сообщение: Avoiding a seq scan on a table.
Следующее
От: "Sean Davis"
Дата:
Сообщение: Re: Avoiding a seq scan on a table.