From: | "Merlin Moncure" <merlin(dot)moncure(at)rcsonline(dot)com> |
---|---|
To: | "Laurent Martelli" <laurent(at)aopsys(dot)com> |
Cc: | <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: Speeding up select distinct |
Date: | 2005-03-16 18:56:07 |
Message-ID: | 6EE64EF3AB31D5448D0007DD34EEB3412A7651@Herge.rcsinc.local |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
> I just wished there was a means to fully automate all this and render
> it transparent to the user, just like an index.
>
> Merlin> Voila! Merlin p.s. normalize your data always!
>
> I have this:
>
> pictures(
> PictureID serial PRIMARY KEY,
> Owner integer NOT NULL REFERENCES users,
> [...]);
> CREATE TABLE users (
> UserID serial PRIMARY KEY,
> Name character varying(255),
> [...]);
>
> Isn't it normalized ?
try:
select * from users where UserID in (select pictureId from pictures);
select * userid from users intersect select pictureid from pictures;
select distinct userid, [...] from users, pictures where user userid =
pictureid)
if none of these give you what you want then you can solve this with a
new tble, picture_user using the instructions I gave previously.
Not sure if your data is normalized, but ISTM you are over-using
surrogate keys. It may not be possible, but consider downgrading ID
columns to unique and picking a natural key. Now you get better benefit
of RI and you can sometimes remove joins from certain queries.
Rule: use natural keys when you can, surrogate keys when you have to.
Corollary: use domains for fields used in referential integrity.
Merlin
From | Date | Subject | |
---|---|---|---|
Next Message | Greg Stark | 2005-03-16 19:45:26 | Re: cpu_tuple_cost |
Previous Message | Rod Taylor | 2005-03-16 18:41:04 | Re: Speeding up select distinct |