|
|
Posted by Erland Sommarskog on 07/24/07 22:16
bobdurie@gmail.com (bobdurie@gmail.com) writes:
> Thank you very much for the insight!! More followups:
>
> For this query/purge idead:
> SELECT @loadid = MAX(LoadID)
> FROM loads
> WHERE CreateDate < dateadd(SECOND, -40, CURRENT_TIMESTAMP);
> DELETE loads WHERE LoadID <= @loadid;
>
> Why would i need an index on CreateDate,LoadiD ? Is it just for the
> first query, or would the DELETE actually need it too?
Only for the first query, obviously.
> I'd be tempted to do the first query with READ_UNCOMMITTED transaction
> level, then do the DELETE on another default transaction isolation level
> connection.
Most likely, it will scan the table which is not good for overall
performance. But, yes, from a purely functional standpoint, you can
run with READ UNCOMMITTED.
> One other thing that i don't understand - whats with the DESC
> indexes? I would understand for queries where you'r doing a DESC
> orderby, but what other purpose to they serve?
For the index on (Type, LoadID), I added DESC since you had that in
the ORDER BY clause. For the suggested index on (CreateDate, LoadID)
I will have to admit that I don't for sure that it's useful. But I
was think that the optimizer would come in from right, and it would
be good if the first row with the matching CreateDate and the good
LoadID.
--
Erland Sommarskog, SQL Server MVP, esquel@sommarskog.se
Books Online for SQL Server 2005 at
http://www.microsoft.com/technet/prodtechnol/sql/2005/downloads/books.mspx
Books Online for SQL Server 2000 at
http://www.microsoft.com/sql/prodinfo/previousversions/books.mspx
Navigation:
[Reply to this message]
|