|
Home > Archive > PostgreSQL Discussion > September 2005 > Many-To-Many Bridge Table Index
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
Many-To-Many Bridge Table Index
|
|
| Sergei Dubov 2005-09-30, 1:23 pm |
| 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.
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?
Thanks so much,
Serge
---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?
http://www.postgresql.org/docs/faq
| |
| Dawid Kuroczko 2005-09-30, 8:23 pm |
| On 9/30/05, Sergei Dubov <sdubov@gmail.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
|
|
|
|
|