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.
Re: Avoiding a seq scan on a table. |
Список | 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 по дате отправления: