Re: Yet another indexing issue. - Mailing list pgsql-general

From Stephan Szabo
Subject Re: Yet another indexing issue.
Date
Msg-id 20020319155803.G37657-100000@megazone23.bigpanda.com
Whole thread Raw
In response to Re: Yet another indexing issue.  ("David Siebert" <david@eclipsecat.com>)
Responses View INSERTs not returning OID in Postgres 7.2.1  (Damon Cokenias <lists@mtn-palace.com>)
List pgsql-general
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?


pgsql-general by date:

Previous
From: "Jonathan Ellis"
Date:
Subject: Re: locking problems
Next
From: Travis Bauer
Date:
Subject: PL/PGSQL and PL/Perl time issues