Re: Why the planner is not using the INDEX . - Mailing list pgsql-performance

From Stephan Szabo
Subject Re: Why the planner is not using the INDEX .
Date
Msg-id 20050705065351.W63027@megazone.bigpanda.com
Whole thread Raw
In response to Re: Why the planner is not using the INDEX .  (David Gagnon <dgagnon@siunik.com>)
List pgsql-performance
On Mon, 4 Jul 2005, David Gagnon wrote:

> Thanks .. I miss that FK don't create indexed ...  since Primary key
> implicitly does ...
>
> I'm a bit surprised of that behavior thought, since it means that if we
> delete a row from table A all tables (B,C,D) with FK pointing to this
> table (A) must be scanned.
> If there is no index on those tables it means we gone do all Sequantial
> scans. Than can cause significant performance problem!!!.
>
> Is there a reason why implicit index aren't created when FK are
> declared.  I looked into the documentation and I haven't found a way to

The reason is that it's not always useful to have an index for that
purpose.  You could either have low selectivity (in which case the index
wouldn't be used) or low/batch changes to the referenced table (in which
case the cost of maintaining the index may be greater than the value of
having the index) or other such cases.  In primary key and unique, we
currently have no choice but to make an index because that's how the
constraint is currently implemented.

> tell postgresql to automatically create an index when creating la FK.
> Does it means I need to manage it EXPLICITLY with create index statement
> ?

Yeah.

>Is there another way ?

Not that I can think of without changing the source.

pgsql-performance by date:

Previous
From: Bruno Wolff III
Date:
Subject: Re: Why the planner is not using the INDEX .
Next
From: Tom Lane
Date:
Subject: Re: Why the planner is not using the INDEX .