Post reply

Diagnosing parallelism-related latching

  • May 26, 2016 at 12:04 am

    #307994

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

  • May 26, 2016 at 12:48 am

    #1881490

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

  • May 26, 2016 at 6:37 am

    #1881533

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

    "I 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

  • May 26, 2016 at 7:22 am

    #1881545

    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.

  • May 26, 2016 at 11:13 am

    #1881622

    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.

  • May 26, 2016 at 11:40 am

    #1881628

    @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 5 (of 5 total)

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