Re: constraint with reference to the same table - Mailing list pgsql-performance

From Victor Yegorov
Subject Re: constraint with reference to the same table
Date
Msg-id 20030515015811.GE1549@nordlb.lv
Whole thread Raw
In response to Re: constraint with reference to the same table  (Rudi Starcevic <rudi@oasis.net.au>)
Responses Re: constraint with reference to the same table  (Rudi Starcevic <rudi@oasis.net.au>)
List pgsql-performance
* Rudi Starcevic <rudi@oasis.net.au> [15.05.2003 04:46]:
> Stephen,
>
>
> New:
> CREATE TABLE business_person
> (
> b_id integer REFERENCES business ON UPDATE CASCADE ON DELETE CASCADE NOT
> NULL,
> pn_id integer REFERENCES person ON UPDATE CASCADE ON DELETE CASCADE NOT NULL
> PRIMARY KEY(b_id,pn_id);
> );
> CREATE INDEX b_pn_b_id_idx  ON business_person (b_id);
> CREATE INDEX b_pn_pn_id_idx ON business_person (pn_id);

May be it's better to name indexes a bit more clearer? No impact on overall
performance, but you'll ease your life, if you project will grow to hundreds
of tables and thousands of indicies.

> As I'd like to sometime's look up business's, sometime's look up people and
> sometimes
> look up both I think I should keep the Index's.

If your lookups are part of business logic, than it's ok. Also, if your
system generates reports using several table joins that may speed up the
things.

Otherwise, for curiosity cases, it's better to wait some time for the result
of one-time queries.

--

Victor Yegorov

pgsql-performance by date:

Previous
From: "T. Alex Beamish"
Date:
Subject: INNER JOIN vs WHERE
Next
From: Rudi Starcevic
Date:
Subject: Re: constraint with reference to the same table