From: | Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
---|---|
To: | Jack Coates <jack(at)lyris(dot)com> |
Cc: | pgsql-performance <pgsql-performance(at)postgresql(dot)org> |
Subject: | Re: query optimization question |
Date: | 2004-01-29 19:31:11 |
Message-ID: | 26581.1075404671@sss.pgh.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Jack Coates <jack(at)lyris(dot)com> writes:
> jackdb=# explain SELECT DISTINCT members_.memberid_
> jackdb-# FROM members_
> jackdb-# WHERE ( members_.List_='list1'
> jackdb(# AND members_.MemberType_='normal'
> jackdb(# AND members_.SubType_='mail'
> jackdb(# AND members_.emailaddr_ IS NOT NULL )
> jackdb-# GROUP BY memberid_ HAVING (
Um, that's not what I had in mind at all. Does GROUP BY actually do
anything at all here? (You didn't answer me as to whether memberid_
is a unique identifier or not, but if it is, this GROUP BY is just an
expensive no-op.)
What I was envisioning was pulling the sub-selects up to the top level
and using grouping to calculate the count(*) values for all memberids
in parallel. Roughly speaking it would look like (again assuming
memberid_ is unique)
SELECT memberid_ FROM
(
SELECT memberid_ FROM lyrActiveRecips, members_, outmail
WHERE (all the conditions for this case)
UNION ALL
SELECT memberid_ FROM lyrCompletedRecips, members_, outmail
WHERE (all the conditions for this case)
)
GROUP BY memberid_ HAVING count(*) = 3;
However, if you can't change the boilerplate part of your query then
this is all blue-sky speculation anyway. What I'm actually more
interested in is your statement that MSSQL can do the original query
quickly. I find that a bit hard to believe because I don't see any
relevant optimization techniques. Do they have any equivalent to
EXPLAIN that would give some hint how they're doing it?
regards, tom lane
From | Date | Subject | |
---|---|---|---|
Next Message | Bill Moran | 2004-01-29 19:44:28 | Re: [PERFORM] Set-Returning Functions WAS: On the performance of |
Previous Message | lnd | 2004-01-29 19:29:59 | Explain plan for 2 column index |