tag:blogger.com,1999:blog-3702702923592093288.post5515633462109129239..comments2023-11-25T05:29:22.718+13:00Comments on Page Free Space: SQL Server 2019 Aggregate SplittingPaul Whitehttp://www.blogger.com/profile/04690243284528295117noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-3702702923592093288.post-33301823100675393482020-08-12T10:22:27.184+12:002020-08-12T10:22:27.184+12:00Code comment typo! Thank you, I have fixed that.
...Code comment typo! Thank you, I have fixed that.<br /><br />Yes the MAX_GRANT_PERCENT setting was adjusted by hand. Not the *minimum* memory though, the *desired* memory. In any case, it is to simulate a hashing operation too large to perform entirely in memory, given the current hardware and configuration.Paul Whitehttps://www.blogger.com/profile/04690243284528295117noreply@blogger.comtag:blogger.com,1999:blog-3702702923592093288.post-69312860484430473422020-08-12T07:54:03.491+12:002020-08-12T07:54:03.491+12:00Hi Paul
Thank you for this post, really useful inf...Hi Paul<br />Thank you for this post, really useful info.<br />Just one thought - I think there is a small typo in the first code snippet in the "Test 1 - No splitting" section. It says the ('QUERY_OPTIMIZER_COMPATIBILITY_LEVEL_140') hint controls "No aggregate spilling", but I believe this was meant to be "No aggregate splitting".<br /><br />Also, one question - how did you come up with the MAX_GRANT_PERCENT of 1.1% ? Just fine-tuning the threshold based on the minimum memory this query requires ?<br /><br />Regards<br />Karch (Eugene Karpovich)<br />Anonymoushttps://www.blogger.com/profile/06922045123653234268noreply@blogger.com