Diagnosing parallelism-related latching

  • David Fundakowski

    Ten Centuries

    Points: 1290

    Comments posted to this topic are about the item Diagnosing parallelism-related latching

  • BLOB EATER

    SSChampion

    Points: 14564

    I like the flow of your article, 1 question, why was the cost threshold left at 5?

  • Alan Burstein

    SSC Guru

    Points: 61026

    Good job on the article David. Very well researched, informative and full of great additional resources. 5 stars!

    -- Alan Burstein


    Helpful links:Best practices for getting help on SQLServerCentral -- Jeff ModenHow to Post Performance Problems -- Gail ShawNasty fast set-based string manipulation functions:For splitting strings try DelimitedSplit8K or DelimitedSplit8K_LEAD (SQL Server 2012+)To split strings based on patterns try PatternSplitCMNeed to clean or transform a string? try NGrams, PatExclude8K, PatReplace8K, DigitsOnlyEE, or Translate8KI cant stress enough the importance of switching from a sequential files mindset to set-based thinking. After you make the switch, you can spend your time tuning and optimizing your queries instead of maintaining lengthy, poor-performing code.  -- Itzik Ben-Gan 2001

  • akljfhnlaflkj

    SSC Guru

    Points: 76202

    Good read on this subject. We've used MAXDOP in the past when we were redesigning our database and had to migrate tons of data. It has its place.

  • Claudiu Balciza

    SSC Enthusiast

    Points: 191

    Do you need to include the survey_id in the nonclustered index?

    The nonclustered indexes contain a reference to the primary key if there's one and in your case it seems the survey_id is the clustered PK.

  • David Fundakowski

    Ten Centuries

    Points: 1290

    @Blob_Eater: We left it at that moment because the issue was in our production system. We wanted to make controlled changes and monitor what the result was. There have been several discussions since this issue about parallel plans and finding other big offenders.

    @alan.B: Thank you very much

    @Iwas Bornready: Agreed. In this case, the query was ripe for an index so it made more sense to add that instead of defining a MAXDOP on the query.

    @Claudiu Balciza: We actually have the PK on another column that is based on the survey response, not survey ID.

Viewing 6 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply