On Tue, Dec 03, 2002 at 11:01:33AM -0800, eric soroos wrote:
> I'm having trouble subtracting groups from other groups.
>
>
> I've got a data model that has the following essential features:
>
> create table contacts (num int, properties....);
> create table groups (groupNum int, contactNum int);
>
> Where not all contacts will be in a group, some groups will contain most contacts,
>and there will be something like hundreds of groups and tens of thousands of
>contacts. I allow people to build groups using criteria, which I need to
>programatically translate to sql.
>
> One somewhat common pattern is:
>
> Select all contacts in group a, who have property b, and who aren't in groups
>c,d,e,f...
>
> My first shot was subqueries:
>
> select num, p1,p2 ... from contacts
> inner join groups using (contacts.num=groups.contactNum)
> where groups.groupNum=a
> and contact.p3=b
> and not num in (select contactNum from groups where groupNum=c)
> and not num in (select contactNum from groups where groupNum=d)
> and not num in (select contactNum from groups where groupNum=e)
> and not num in (select contactNum from groups where groupNum=f)
>
> This is .... slow. agonizingly so.
I'd say so!
Something like:
SELECT * ...
FROM ...
WHERE NOT IN (SELECT contactnum FROM groups WHERE groupnum='c' or
groupnum='d' OR ... )
is bound to be _much_ faster!
And even better is
SELECT *
FROM ... contacts c1
WHERE NOT EXISTS (SELECT * FROM groups WHERE groupname='c' or
groupnum='d' or groupnume='e' ... AND groups.contactnum=c1.contactnum)
EXISTS is almost always faster in PG.
--
Joel BURTON | [EMAIL PROTECTED] | joelburton.com | aim: wjoelburton
Independent Knowledge Management Consultant
---------------------------(end of broadcast)---------------------------
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
