Re: Yet another indexing issue.

On Tue, 19 Mar 2002, David Siebert wrote:

> Here is the explain output
>
> Sort  (cost=293.24..293.24 rows=1 width=128)
>   ->  Seq Scan on phonecalls  (cost=0.00..293.23 rows=1 width=128)
>
> Here is the Table
> CREATE TABLE "phonecalls" (
>   "irecnum" int4 DEFAULT nextval('"phonecalls_irecnum_seq"'::text) NOT NULL,
>   "scaller" varchar(80),
>   "sphone" varchar(40),
>   "sphone2" varchar(40),
>   "squedby" varchar(40),
>   "sfor" varchar(40),
>   "dplaceddate" timestamp,
>   "dtakendate" timestamp,
>   "dresdate" timestamp,
>   "ipri" int4,
>   "istatus" int4,
>   "iresolution" int4,
>   "ireques" int4,
>   "snotes" varchar(3999),
>   "stakenby" varchar(40),
>   CONSTRAINT "phonecalls_irecnum_key" UNIQUE ("irecnum")
> );
>

> Where would one find set enable_seqscan=off; in the docs?

To be honest I'm not sure where it's mentioned.  It's a big tool that
lets you make some gross changes to the optimizer's planning (sets the
cost of sequence scan very very high).

Does doing it before the explain change the output?

Also, does making an index on phonecalls(istatus, sfor) [rather than
sfor,istatus] change the choice?