July 16, 2023 at 7:06 pm
I just realized that both Jonathans and Jeffs queries used all 8 cores and mine just used 1 core. So here is the same query with parallell plan
As you know, "It Depends" a whole lot on CTFP. I normally have that set at 50 and none of them go parallel there. If I set it to 5, they all go parallel. Well, unless you have MAXDOP set to 1. 😀
Shifing gears a bit, the original issue doesn't sit well with me at all. If it's a "data cleansing" issue coming in from a 3rd party, they need to be told to fix their junk. If it's coming from internal sources, they need to be told to fix their junk. If this is a permanent table, there should be a constraint to prevent such partial duplication and, possible, a trigger to find old junk and auto-automagically fix the junk not to mention saving whatever is perceived to be junk rows to build up evidence to present when you tell someone to fix their junk. 😀
I also seriously question the mechanism that created to original rows that were skipped. Which rows are actually the truth?
😀
--Jeff Moden
Change is inevitable... Change for the better is not.
July 16, 2023 at 7:10 pm
Yes, we both should have noticed that, but our methods are more general in that they will return the entire row that contains the max date even if some of the other columns were not duplicated.
True DAT! 😀
btw did you try disabling hyperthreading?
Not yet.
--Jeff Moden
Change is inevitable... Change for the better is not.
Viewing 2 posts - 16 through 16 (of 16 total)
You must be logged in to reply to this topic. Login to reply