Re: Many-To-Many Bridge Table Index

From: Dawid Kuroczko <qnex42(at)gmail(dot)com>
To: Sergei Dubov <sdubov(at)gmail(dot)com>
Cc: pgsql-general(at)postgresql(dot)org
Subject: Re: Many-To-Many Bridge Table Index
Date: 2005-09-30 21:46:35
Message-ID: 758d5e7f0509301446j47f03740ma582e011551d4ce7@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

On 9/30/05, Sergei Dubov <sdubov(at)gmail(dot)com> wrote:
>
> Hi guys,
>
> I'd really appreciate if you could clarify this to me. Let's say I have
> a table named TABLE_A that is a bridge to many-to-many relationship
> between TABLE_B and TABLE_C, as such here is my declaration:
>
> CREATE TABLE table_a (
> table_b_id INT4 NOT NULL
> REFERENCES table_b ON DELETE CASCADE ON UPDATE CASCADE,
>
> table_c_id INT4 NOT NULL
> REFERENCES table_c ON DELETE RESTRICT ON UPDATE CASCADE,
>
> CONSTRAINT table_a_pkey
> PRIMARY KEY (table_b_id, table_c_id)
> );
>
> This will automatically create a unique index on the primary key.

Yes it will. Primary keys in PostgreSQL are implemented
using unique indexes, one may say.

> Well, if I do a query later like:
> select * from table_a where table_b_id=1,
> will the query use an index? Will this be true when I do join on this
> table?

The short answer is: yes.

The longer answer is: yes, when planner sees that the index is the most
efficient way to approach given query. In some cases using sequentional
scan may be more efficient.

Try EXPLAIN ANALYZE SELECT ...; -- it will tell you what did the planer
choose.

Regards,
Dawid

In response to

Browse pgsql-general by date

  From Date Subject
Next Message Sean Davis 2005-09-30 22:24:52 Query optimization
Previous Message Fernando Grijalba 2005-09-30 20:29:36 Re: Help with inventory control - THANK YOU!!!