Re: Avoiding a seq scan on a table. - Mailing list pgsql-novice

From LWATCDR
Subject Re: Avoiding a seq scan on a table.
Date
Msg-id 8c38cea40801140845n2f52babft789d5f7cc2140ffc@mail.gmail.com
Whole thread Raw
In response to Avoiding a seq scan on a table.  (LWATCDR <lwatcdr@gmail.com>)
Responses 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>)
List 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 by date:

Previous
From: LWATCDR
Date:
Subject: Avoiding a seq scan on a table.
Next
From: "Sean Davis"
Date:
Subject: Re: Avoiding a seq scan on a table.