Sub-query within a view optimization

Question

I have a view that reads from two tables Call and Caller , both those tables are parallel in that they are keyed on the same ID (ie to get the Caller information for a Call, you join on Call.id = Caller.id). I have a view that spans these two tables to return composite information about any particular call or set of calls.

But I have a subquery in that view that is used to determine if the caller has been called back or not (defined as there exists another call for the same phone number made after this call with a status of completed). This subquery is making the view extremely slow to query but I'm not sure what would be a better way to include this information. Below are the relevant DDLs, thoughts?

Edit: Would this query be fine with some indexes added or would there be a more efficient way to structure the query itself?

CREATE TABLE [CALL]
(
    ID VARCHAR(64) PRIMARY KEY, --this is a legacy system, I know varchar(64) isn't an efficient primary key
    CALLDATE DATETIME,
    STATUS BIT --1 = Complete, 0 = Incomplete
)

CREATE TABLE [CALLER]
(
    ID VARCHAR(64) PRIMARY KEY,
    PHONENUMBER VARCHAR(10),
    FIRSTNAME VARCHAR(50),
    LASTNAME VARCHAR(50)
)

CREATE VIEW [CALLVIEW] AS
SELECT
    CALL.ID AS CALLID,
    CALL.CALLDATE AS CALLDATE,
    CALL.STATUS AS CALLSTATUS,
    CALLER.PHONENUMBER AS PHONENUMBER,
    CALLER.FIRSTNAME AS FIRSTNAME,
    CALLER.LASTNAME AS LASTNAME,
    CAST(CASE WHEN EXISTS (SELECT TOP 1 1
                           FROM [CALL] CALL2
                           INNER JOIN [CALLER] CALLER2 ON CALL2.ID = CALLER2.ID
                           WHERE CALLER2.PHONENUMBER = CALLER.PHONENUMBER
                           AND CALL2.CALLDATE > CALL.CALLDATE
                           AND CALL2.STATUS = 1) THEN 1 ELSE 0 END AS BIT) AS CALLEDBACK
FROM
    [CALL]
    INNER JOIN [CALLER] ON [CALL].ID = [CALLER].ID

Edit: From the execution plan I notice that by far the most expensive components of the query are the following:

Clustered Index Seek

Predicate: CALL2.CALLDATE > CALL.CALLDATE AND CALL2.STATUS = 1

Object: [CALL].[PK_CALL] CALL2 (so it's using the primary key index)

Output List: [CALL].CALLDATE, [CALL].STATUS

Seek Predicates: [CALL].id = Scalar Operator([CALLER].id)

Index Seek

Object: [CALLER].[IX_PHONENUMBER] CALLER2 (so it's using the proper index but still expensive?)

Output List: [CALLER].ID

Seek Predicates: [CALLER].PHONENUMBER = Scalar Operator([CALLER].PHONENUMBER)

Answer 1

First, try to use the Database Engine Tuning Advisor , it'll tell you if you need to create some indexes.

Anyway, here's what I'd do:

• Verify that you actually have a CLUSTERED Index on CALL.ID and on CALLER.ID (being a legacy system, maybe you have the PK but someone dropped the index)
• Create NON CLUSTERED Index on:
  • CALLER.PHONENUMBER
  • CALL.CALLDATE
  • CALL.STATUS
• Reorganize/Rebuild Indexes
• Update Statistics