Thanks!
---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
subscribe-nomail command to [EMAIL PROTECTED] so that your
message can get through to the mailing list cleanly
danmcb wrote:
SELECT * from my_table where id_1 = x and id_2 = y;
Neither id_1 or id_2 or the combination of them is unique. I expect
this table to become large over time.
PFC wrote:
Create an index on (id_1, id_2), or (id_2,id_1).
What are the strengths and weaknesses compared to creating
-Original Message-
From: [EMAIL PROTECTED] [mailto:pgsql-general-
[EMAIL PROTECTED] On Behalf Of Lew
Sent: Tuesday, May 29, 2007 6:38 AM
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] optimisation for a table with frequently used
query
danmcb wrote:
SELECT * from
I just did some checks on two seperate indexes c.f. one combined one.
I saw almost no difference between making select statements.
Haven't tried what happens with many updates - makes sense that more
indexes will slow that down though.
again thanks - bit of a noob question I know, but it's good
again thanks - bit of a noob question I know, but it's good to
learn :-)
Well not really since the answer is quite subtle...
You kave two columns A and B.
Say you have index on A, and index on B.
These queries will make direct use of the index :
A=...
Hi,
I have a table that looks like this:
CREATE TABLE my_table {
id SERIAL PRIMARY KEY,
id_1 INTEGER REFERENCES tab1(id),
id_2 INTEGER REFERENCES tab2(id),
.
.
.
};
I will often be running queries that look like
SELECT * from my_table where id_1 = x and id_2 = y;
Neither id_1 or
SELECT * from my_table where id_1 = x and id_2 = y;
Neither id_1 or id_2 or the combination of them is unique. I expect
this table to become large over time.
Create an index on (id_1, id_2), or (id_2,id_1).
---(end of broadcast)---
TIP 9: In
