Skip site navigation (1) Skip section navigation (2)

Re: Avoiding a seq scan on a table.

From: LWATCDR <lwatcdr(at)gmail(dot)com>
To: "Brian Hurt" <bhurt(at)janestcapital(dot)com>
Cc: "pgsql-novice(at)postgresql(dot)org" <pgsql-novice(at)postgresql(dot)org>
Subject: Re: Avoiding a seq scan on a table.
Date: 2008-01-14 16:45:53
Message-ID: (view raw, whole thread or download thread mbox)
Lists: 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(at)janestcapital(dot)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

In response to


pgsql-novice by date

Next:From: Sean DavisDate: 2008-01-14 16:54:30
Subject: Re: Avoiding a seq scan on a table.
Previous:From: LWATCDRDate: 2008-01-14 16:21:37
Subject: Avoiding a seq scan on a table.

Privacy Policy | About PostgreSQL
Copyright © 1996-2017 The PostgreSQL Global Development Group