Slow query

[DFS]

This UNION query is very slow. With only 3,000 records in the Parent table
and 7,000 records in the Child table, it takes about 60 seconds to run and
returns about 2200 records.

Access 97. All appropriate indexes and keys enforced.

Any ideas on speeding it up? Thanks.
-- PART 1: HAS NO CHILD RECORDS

SELECT P.PROJECT_ID, 'No Child Data' AS SUB_TYPE
FROM PROJECTS P LEFT JOIN PROJECTS_CHILDR EN C
ON P.PROJECT_ID = C.PROJECT_ID
WHERE P.PROJECT_ID IS NULL

UNION

-- PART 2: HAS CHILD RECORDS, BUT NOT OF TYPE Z

SELECT PROJECT_ID, 'Child Data, Not type Z' AS SUB_TYPE
FROM PROJECTS
WHERE PROJECT_ID NOT IN

(
(SELECT PROJECT_ID
FROM PROJECTS_CHILDR EN
WHERE CHILD_TYPE Like "Z*")

AND

PROJECT_ID NOT IN (
SELECT P.PROJECT_ID
FROM PROJECTS P LEFT JOIN PROJECTS_CHILDR EN C
ON P.PROJECT_ID = C.PROJECT_ID
WHERE P.PROJECT_ID IS NULL)
);

[Peter Doering]

On Mon, 2 Feb 2004 19:20:01 -0500, DFS wrote:

This UNION query is very slow. With only 3,000 records in the Parent table
and 7,000 records in the Child table, it takes about 60 seconds to run and
returns about 2200 records.

Access 97. All appropriate indexes and keys enforced.

Any ideas on speeding it up? Thanks.

-- PART 1: HAS NO CHILD RECORDS

SELECT P.PROJECT_ID, 'No Child Data' AS SUB_TYPE
FROM PROJECTS P LEFT JOIN PROJECTS_CHILDR EN C
ON P.PROJECT_ID = C.PROJECT_ID
WHERE P.PROJECT_ID IS NULL
This doesn't match your explanation. As I understand:
WHERE C.PROJECT_ID IS NULL
UNION

-- PART 2: HAS CHILD RECORDS, BUT NOT OF TYPE Z

SELECT PROJECT_ID, 'Child Data, Not type Z' AS SUB_TYPE
FROM PROJECTS
WHERE PROJECT_ID NOT IN

(
(SELECT PROJECT_ID
FROM PROJECTS_CHILDR EN
WHERE CHILD_TYPE Like "Z*")

AND

PROJECT_ID NOT IN (
SELECT P.PROJECT_ID
FROM PROJECTS P LEFT JOIN PROJECTS_CHILDR EN C
ON P.PROJECT_ID = C.PROJECT_ID
WHERE P.PROJECT_ID IS NULL)
Same, see above.
);

1. There is no link between main and sub-queries in the 2nd part. Therefore
the sub-queries will run on the entire table for each entry of the
main-query.

2. There seems to be a problem with the combined sub-queries in the Not In
clause of the 2nd query. With split clauses you should have reasonable
results:

SELECT P.PROJECT_ID, 'No Child Data' AS SUB_TYPE
FROM PROJECTS P LEFT JOIN PROJECTS_CHILDR EN C
ON P.PROJECT_ID = C.PROJECT_ID
WHERE C.PROJECT_ID IS NULL

UNION

SELECT P.PROJECT_ID, 'Child Data, Not type Z' AS SUB_TYPE
FROM PROJECTS P
WHERE P.PROJECT_ID NOT IN

(SELECT C.PROJECT_ID
FROM PROJECTS_CHILDR EN C
WHERE C.PROJECT_ID = P.PROJECT_ID
AND C.CHILD_TYPE Like "Z*")

AND P.PROJECT_ID NOT IN

(SELECT Q.PROJECT_ID
FROM PROJECTS Q LEFT JOIN PROJECTS_CHILDR EN C
ON Q.PROJECT_ID = C.PROJECT_ID
WHERE Q.PROJECT_ID=P. PROJECT_ID
AND C.PROJECT_ID IS NULL);

HTH - Peter

--
No mails please.

[Lyle Fairfield]

"DFS" <no****@nospam. com> wrote in
news:10******** *****@corp.supe rnews.com:

This UNION query is very slow. With only 3,000 records in the Parent
table and 7,000 records in the Child table, it takes about 60 seconds to
run and returns about 2200 records.

Access 97. All appropriate indexes and keys enforced.

Any ideas on speeding it up? Thanks.
-- PART 1: HAS NO CHILD RECORDS

SELECT P.PROJECT_ID, 'No Child Data' AS SUB_TYPE
FROM PROJECTS P LEFT JOIN PROJECTS_CHILDR EN C
ON P.PROJECT_ID = C.PROJECT_ID
WHERE P.PROJECT_ID IS NULL

UNION

-- PART 2: HAS CHILD RECORDS, BUT NOT OF TYPE Z

SELECT PROJECT_ID, 'Child Data, Not type Z' AS SUB_TYPE
FROM PROJECTS
WHERE PROJECT_ID NOT IN

(
(SELECT PROJECT_ID
FROM PROJECTS_CHILDR EN
WHERE CHILD_TYPE Like "Z*")

AND

PROJECT_ID NOT IN (
SELECT P.PROJECT_ID
FROM PROJECTS P LEFT JOIN PROJECTS_CHILDR EN C
ON P.PROJECT_ID = C.PROJECT_ID
WHERE P.PROJECT_ID IS NULL)

"NOT IN" is a pig. TRY a Left Join and WHERE ISNULL(The Child Table Linked
Field)

--
Lyle
(for e-mail refer to http://ffdba.com/contacts.htm)

[Salad]

DFS wrote:

This UNION query is very slow. With only 3,000 records in the Parent table
and 7,000 records in the Child table, it takes about 60 seconds to run and
returns about 2200 records.

Access 97. All appropriate indexes and keys enforced.

Any ideas on speeding it up? Thanks.

-- PART 1: HAS NO CHILD RECORDS

SELECT P.PROJECT_ID, 'No Child Data' AS SUB_TYPE
FROM PROJECTS P LEFT JOIN PROJECTS_CHILDR EN C
ON P.PROJECT_ID = C.PROJECT_ID
WHERE P.PROJECT_ID IS NULL
I was thinking C.ProjectID is null. Oh weel.
UNION

-- PART 2: HAS CHILD RECORDS, BUT NOT OF TYPE Z

SELECT PROJECT_ID, 'Child Data, Not type Z' AS SUB_TYPE
FROM PROJECTS
WHERE PROJECT_ID NOT IN

(
(SELECT PROJECT_ID
FROM PROJECTS_CHILDR EN
WHERE CHILD_TYPE Like "Z*")
That's your speed demon killer. The In (Select....) methd, from all of my
experiences, is useful for coffee breaks.

AND

PROJECT_ID NOT IN (
SELECT P.PROJECT_ID
FROM PROJECTS P LEFT JOIN PROJECTS_CHILDR EN C
ON P.PROJECT_ID = C.PROJECT_ID
WHERE P.PROJECT_ID IS NULL)
);

Ok, you have a double whammy speed demon killer.

[DFS]

"Salad" <oi*@vinegar.co m> wrote in message
news:40******** *******@vinegar .com...

DFS wrote:

This UNION query is very slow. With only 3,000 records in the Parent table and 7,000 records in the Child table, it takes about 60 seconds to run and returns about 2200 records.

Access 97. All appropriate indexes and keys enforced.

Any ideas on speeding it up? Thanks.

-- PART 1: HAS NO CHILD RECORDS

SELECT P.PROJECT_ID, 'No Child Data' AS SUB_TYPE
FROM PROJECTS P LEFT JOIN PROJECTS_CHILDR EN C
ON P.PROJECT_ID = C.PROJECT_ID
WHERE P.PROJECT_ID IS NULL

I was thinking C.ProjectID is null. Oh weel.

Yes, you're right - I cut and pasted and changed a few things before I
posted.

UNION

-- PART 2: HAS CHILD RECORDS, BUT NOT OF TYPE Z

SELECT PROJECT_ID, 'Child Data, Not type Z' AS SUB_TYPE
FROM PROJECTS
WHERE PROJECT_ID NOT IN

(
(SELECT PROJECT_ID
FROM PROJECTS_CHILDR EN
WHERE CHILD_TYPE Like "Z*")

That's your speed demon killer. The In (Select....) methd, from all of my
experiences, is useful for coffee breaks.

This is the slow part. All other parts of the query run in 1 second or
less.

AND

PROJECT_ID NOT IN (
SELECT P.PROJECT_ID
FROM PROJECTS P LEFT JOIN PROJECTS_CHILDR EN C
ON P.PROJECT_ID = C.PROJECT_ID
WHERE P.PROJECT_ID IS NULL)
);

Ok, you have a double whammy speed demon killer.

This part runs fast, about 1 second.

Thanks.

[DFS]

"Lyle Fairfield" <Mi************ @Invalid.Com> wrote in message
news:Xn******** ***********@130 .133.1.4...

"DFS" <no****@nospam. com> wrote in
news:10******** *****@corp.supe rnews.com:

This UNION query is very slow. With only 3,000 records in the Parent
table and 7,000 records in the Child table, it takes about 60 seconds to
run and returns about 2200 records.

Access 97. All appropriate indexes and keys enforced.

Any ideas on speeding it up? Thanks.
-- PART 1: HAS NO CHILD RECORDS

SELECT P.PROJECT_ID, 'No Child Data' AS SUB_TYPE
FROM PROJECTS P LEFT JOIN PROJECTS_CHILDR EN C
ON P.PROJECT_ID = C.PROJECT_ID
WHERE P.PROJECT_ID IS NULL

UNION

-- PART 2: HAS CHILD RECORDS, BUT NOT OF TYPE Z

SELECT PROJECT_ID, 'Child Data, Not type Z' AS SUB_TYPE
FROM PROJECTS
WHERE PROJECT_ID NOT IN

(
(SELECT PROJECT_ID
FROM PROJECTS_CHILDR EN
WHERE CHILD_TYPE Like "Z*")

AND

PROJECT_ID NOT IN (
SELECT P.PROJECT_ID
FROM PROJECTS P LEFT JOIN PROJECTS_CHILDR EN C
ON P.PROJECT_ID = C.PROJECT_ID
WHERE P.PROJECT_ID IS NULL)

"NOT IN" is a pig. TRY a Left Join and WHERE ISNULL(The Child Table Linked
Field)

Yes, the "NOT IN" section is the only slow part - actually, the first NOT IN
is slow, but the last one runs quickly. I'll try a LEFT JOIN for the first
section as well.

Danke.

[DFS]

"Peter Doering" <no****@doering .org> wrote in message
news:bv******** ****@ID-204768.news.uni-berlin.de...

On Mon, 2 Feb 2004 19:20:01 -0500, DFS wrote:

This UNION query is very slow. With only 3,000 records in the Parent table and 7,000 records in the Child table, it takes about 60 seconds to run and returns about 2200 records.

Access 97. All appropriate indexes and keys enforced.

Any ideas on speeding it up? Thanks.

-- PART 1: HAS NO CHILD RECORDS

SELECT P.PROJECT_ID, 'No Child Data' AS SUB_TYPE
FROM PROJECTS P LEFT JOIN PROJECTS_CHILDR EN C
ON P.PROJECT_ID = C.PROJECT_ID
WHERE P.PROJECT_ID IS NULL
This doesn't match your explanation. As I understand:
WHERE C.PROJECT_ID IS NULL

True. I cut and pasted and made some changes to the post manually, and
mistyped. The actual query uses C.PROJECT_ID IS NULL.

UNION

-- PART 2: HAS CHILD RECORDS, BUT NOT OF TYPE Z

SELECT PROJECT_ID, 'Child Data, Not type Z' AS SUB_TYPE
FROM PROJECTS
WHERE PROJECT_ID NOT IN

(
(SELECT PROJECT_ID
FROM PROJECTS_CHILDR EN
WHERE CHILD_TYPE Like "Z*")

AND

PROJECT_ID NOT IN (
SELECT P.PROJECT_ID
FROM PROJECTS P LEFT JOIN PROJECTS_CHILDR EN C
ON P.PROJECT_ID = C.PROJECT_ID
WHERE P.PROJECT_ID IS NULL)

Same, see above.

);

1. There is no link between main and sub-queries in the 2nd part.

Therefore the sub-queries will run on the entire table for each entry of the
main-query.

2. There seems to be a problem with the combined sub-queries in the Not In
clause of the 2nd query. With split clauses you should have reasonable
results:

SELECT P.PROJECT_ID, 'No Child Data' AS SUB_TYPE
FROM PROJECTS P LEFT JOIN PROJECTS_CHILDR EN C
ON P.PROJECT_ID = C.PROJECT_ID
WHERE C.PROJECT_ID IS NULL

UNION

SELECT P.PROJECT_ID, 'Child Data, Not type Z' AS SUB_TYPE
FROM PROJECTS P
WHERE P.PROJECT_ID NOT IN

(SELECT C.PROJECT_ID
FROM PROJECTS_CHILDR EN C
WHERE C.PROJECT_ID = P.PROJECT_ID
AND C.CHILD_TYPE Like "Z*")

AND P.PROJECT_ID NOT IN

(SELECT Q.PROJECT_ID
FROM PROJECTS Q LEFT JOIN PROJECTS_CHILDR EN C
ON Q.PROJECT_ID = C.PROJECT_ID
WHERE Q.PROJECT_ID=P. PROJECT_ID
AND C.PROJECT_ID IS NULL);

HTH - Peter

Pete,

That didn't work. It tells me I have 'Child Data, not type Z' when there
are no child records.

But, if I change the WHERE clause in the last section of your query to read:
WHERE C.PROJECT_ID IS NULL
it returns the correct data in about one second, like I knew it should.

Thanks.

[David W. Fenton]

"DFS" <no****@nospam. com> wrote in
news:10******** *****@corp.supe rnews.com:

UNION

UNION ALL?

Keep in mind that UNION removes duplicates, while UNION ALL doesn't
check. If your component queries won't produce duplicates, UNION ALL
will give you some performance benefit.

--
David W. Fenton http://www.bway.net/~dfenton
dfenton at bway dot net http://www.bway.net/~dfassoc