Are the posted questions getting worse?

  • ChrisM@Work - Thursday, January 18, 2018 9:06 AM

    Sean Lange - Thursday, January 18, 2018 8:51 AM

    WayneS - Thursday, January 18, 2018 8:32 AM

    jasona.work - Wednesday, January 17, 2018 12:27 PM

    I find it amusing that someone responded to a topic (that I'd replied to and hopefully answered the OPs question) with a link to a topic on basically the same thing that I started 4 years ago...

    Not knocking the second respondent, just find it amusing (and yes, I'd completely forgotten about my 4 year old, answered, topic...)

    On more than one occasion, I have googled for a problem that I'm having, only to find that I had asked it here - and it was answered. Sometimes (too frequently...), I don't even recall the original problem.

    I have at least a couple of times ran into a problem and did some searching to find that it was asked here by someone else already....and then answered by me. It really goes full circle when you find your own answer which solves a current problem you are struggling with. Just goes to show that sometimes it is all about context.

    Other times, it's all about the quantity of marbles that have slipped out of the hole in the dilapidated bag...

    LOL yes...and the bag of dilapidated marble slipping.

    _______________________________________________________________

    Need help? Help us help you.

    Read the article at http://www.sqlservercentral.com/articles/Best+Practices/61537/ for best practices on asking questions.

    Need to split a string? Try Jeff Modens splitter http://www.sqlservercentral.com/articles/Tally+Table/72993/.

    Cross Tabs and Pivots, Part 1 – Converting Rows to Columns - http://www.sqlservercentral.com/articles/T-SQL/63681/
    Cross Tabs and Pivots, Part 2 - Dynamic Cross Tabs - http://www.sqlservercentral.com/articles/Crosstab/65048/
    Understanding and Using APPLY (Part 1) - http://www.sqlservercentral.com/articles/APPLY/69953/
    Understanding and Using APPLY (Part 2) - http://www.sqlservercentral.com/articles/APPLY/69954/

  • Jeff Moden - Thursday, January 18, 2018 8:00 AM

    Yep... and it's not just cookies, either.  They use a thing called "spotlight pixels" which doesn't need cookies.

    Shifting gears, I'm really pissed at some of the recruiter's web sites.  I'm not sure how they do it but I saw an interesting job posting (I'm not looking for a new job... just interested in what people post for job descriptions) and visited the web site to read the rest.  For the next 3 days, some recruiter from that company kept sending me emails that said they saw me look at the job and did I have any questions.  I've run into such a thing many times now.  Although I don't like what folks have to do to become GDPR compliant, I can definitely see why a whole lot of consumers want it.  I think I'll buy an IOT toilet so that I can express my opinion to these recruiters in a manner more faithful to my true feelings. πŸ˜‰

    Recruiting is a tough business. Like selling cars. IT's a numbers game and being pushy pays off. Being passive gets to fired.

    The GDPR will be interesting.  If you engage with someone, you've created a business relationship, so it's not like someone can just say stop. You have to terminate the relationship, and then they have 30 days to respond. It's not quite what many people think, especially with the right to be forgotten. That's not easy, and it's mostly for public stuff. Private records, like sales, will still remain.

  • Lynn Pettis - Thursday, January 18, 2018 9:01 AM

    Jeff, Kevin Tate was doing a SQL Server Indexing 101 at our user group meeting last night.  When index maintenance came up I asked if he had read any of the posts where you commented that you needed to go beyond index fragmentation when looking at index reorgs/rebuilds, he hadn't.  Is there a possibility that you may be working on an article or three on what you have been finding in the near future?  There are some of us that want to know.

    ^^^^^ Ahem, paging Mr. Moden

  • Steve Jones - SSC Editor - Thursday, January 18, 2018 10:53 AM

    Jeff Moden - Thursday, January 18, 2018 8:00 AM

    Yep... and it's not just cookies, either.  They use a thing called "spotlight pixels" which doesn't need cookies.

    Shifting gears, I'm really pissed at some of the recruiter's web sites.  I'm not sure how they do it but I saw an interesting job posting (I'm not looking for a new job... just interested in what people post for job descriptions) and visited the web site to read the rest.  For the next 3 days, some recruiter from that company kept sending me emails that said they saw me look at the job and did I have any questions.  I've run into such a thing many times now.  Although I don't like what folks have to do to become GDPR compliant, I can definitely see why a whole lot of consumers want it.  I think I'll buy an IOT toilet so that I can express my opinion to these recruiters in a manner more faithful to my true feelings. πŸ˜‰

    Recruiting is a tough business. Like selling cars. IT's a numbers game and being pushy pays off. Being passive gets to fired.

    The GDPR will be interesting.  If you engage with someone, you've created a business relationship, so it's not like someone can just say stop. You have to terminate the relationship, and then they have 30 days to respond. It's not quite what many people think, especially with the right to be forgotten. That's not easy, and it's mostly for public stuff. Private records, like sales, will still remain.

    Understood... but I didn't give the buggers my email address.  I just visited the site.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)
    Intro to Tally Tables and Functions

  • Lynn Pettis - Thursday, January 18, 2018 9:01 AM

    Jeff, Kevin Tate was doing a SQL Server Indexing 101 at our user group meeting last night.  When index maintenance came up I asked if he had read any of the posts where you commented that you needed to go beyond index fragmentation when looking at index reorgs/rebuilds, he hadn't.  Is there a possibility that you may be working on an article or three on what you have been finding in the near future?  There are some of us that want to know.

    Awesome... thanks for the continued encouragement, ol' friend.

    For starters, I'm working on the presentation on the subject that I'm going to give my user group.  I expect it to take nearly 2 hours and I have to make sure my ducks are lined up.  Ed Wagner and I have done a reboot of the "SPID" user group (SQL PASS In Detroit) and we didn't want to have to sweat finding speakers every month.  At the same time, I had this "plan" to cover my now more than 2 year experiment of not doing any index maintenance on my production boxes and wanted to also explain how that notion got started.

    I did a presentation on CROSS TABS and PIVOTS using a 12 million row table (about a million rows per month) and took them through a bunch of optimization techniques ending with why you might want to build an NCI with a duplication of the keys of the clustered index to quickly isolate and aggregate a month's worth of data (million rows) using a CROSS TAB or PIVOT in less than 600 milliseconds.  Think of it as the first introduction to the true power that can be realized from proper indexing along with a little "Divide'n'Conquer".

    Then, Ed Wagner gave a fabulous talk on indexing that he derived from the PreCon that he and I did for Pittsburgh in October of 2016 to further demonstrate the power of indexes and how the wrong indexes can actually kill performance worse than if you had no indexes, etc, etc.

    From there, we really lucked out to continue the "Index" theme.  Mr. Brent Ozar has agreed to come to Michigan in February to do his presentation on why regular index maintenance based on logical fragmentation (which almost everyone does) can be (and was for Ed and I both) a total waste of time.  In April, Mr. Paul Randal is doing a remote presentation on the subject of indexing where he also talks about the "other kind" of index fragmentation (don't want to cough up any spoilers on that if you've not seen it before).  In May, I'm going to stitch it all together with a case study on my 2 year experiment and some test code that demonstrates what happens to an index over a period of a year (measured every hour for 10 hours per day) both with and without index maintenance, the fallacy of using REORGANIZE, how to auto-magically pick the "best" FILL FACTORs (by index) if you insist on index maintenance and why, the fact that most people are defragging after the most damage is already done, how to identify indexes that actually DO benefit from defragging, etc, etc, etc, all in a very "Alice's Restaurant Fashion" with charts and graphs "with circles, arrows, and a paragraph on the back of each one".

    And, Yes Sir, one of the sides to all this is a couple (maybe three) articles on the subject for SSC.  Not 100% sure when I'll get to that because I have to finish the presentation first and foremost.  Another "side goal" is (possibly) turning it and a couple of additional related subjects into a PreCon so I can afford to get to your SQL Saturday (definitely on my bucket list) and maybe a presentation for the PASS Summit (the only way that I can come close to affording such a thing because I'm just a regular Joe with no sponsors). πŸ˜‰

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)
    Intro to Tally Tables and Functions

  • Steve Jones - SSC Editor - Thursday, January 18, 2018 10:55 AM

    Lynn Pettis - Thursday, January 18, 2018 9:01 AM

    Jeff, Kevin Tate was doing a SQL Server Indexing 101 at our user group meeting last night.  When index maintenance came up I asked if he had read any of the posts where you commented that you needed to go beyond index fragmentation when looking at index reorgs/rebuilds, he hadn't.  Is there a possibility that you may be working on an article or three on what you have been finding in the near future?  There are some of us that want to know.

    ^^^^^ Ahem, paging Mr. Moden

    Heh... What? πŸ˜€ πŸ˜›

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)
    Intro to Tally Tables and Functions

  • Jeff Moden - Thursday, January 18, 2018 5:16 PM

    Lynn Pettis - Thursday, January 18, 2018 9:01 AM

    Jeff, Kevin Tate was doing a SQL Server Indexing 101 at our user group meeting last night.  When index maintenance came up I asked if he had read any of the posts where you commented that you needed to go beyond index fragmentation when looking at index reorgs/rebuilds, he hadn't.  Is there a possibility that you may be working on an article or three on what you have been finding in the near future?  There are some of us that want to know.

    Awesome... thanks for the continued encouragement, ol' friend.

    For starters, I'm working on the presentation on the subject that I'm going to give my user group.  I expect it to take nearly 2 hours and I have to make sure my ducks are lined up.  Ed Wagner and I have done a reboot of the "SPID" user group (SQL PASS In Detroit) and we didn't want to have to sweat finding speakers every month.  At the same time, I had this "plan" to cover my now more than 2 year experiment of not doing any index maintenance on my production boxes and wanted to also explain how that notion got started.

    I did a presentation on CROSS TABS and PIVOTS using a 12 million row table (about a million rows per month) and took them through a bunch of optimization techniques ending with why you might want to build an NCI with a duplication of the keys of the clustered index to quickly isolate and aggregate a month's worth of data (million rows) using a CROSS TAB or PIVOT in less than 600 milliseconds.  Think of it as the first introduction to the true power that can be realized from proper indexing along with a little "Divide'n'Conquer".

    Then, Ed Wagner gave a fabulous talk on indexing that he derived from the PreCon that he and I did for Pittsburgh in October of 2016 to further demonstrate the power of indexes and how the wrong indexes can actually kill performance worse than if you had no indexes, etc, etc.

    From there, we really lucked out to continue the "Index" theme.  Mr. Brent Ozar has agreed to come to Michigan in February to do his presentation on why regular index maintenance based on logical fragmentation (which almost everyone does) can be (and was for Ed and I both) a total waste of time.  In April, Mr. Paul Randal is doing a remote presentation on the subject of indexing where he also talks about the "other kind" of index fragmentation (don't want to cough up any spoilers on that if you've not seen it before).  In May, I'm going to stitch it all together with a case study on my 2 year experiment and some test code that demonstrates what happens to an index over a period of a year (measured every hour for 10 hours per day) both with and without index maintenance, the fallacy of using REORGANIZE, how to auto-magically pick the "best" FILL FACTORs (by index) if you insist on index maintenance and why, the fact that most people are defragging after the most damage is already done, how to identify indexes that actually DO benefit from defragging, etc, etc, etc, all in a very "Alice's Restaurant Fashion" with charts and graphs "with circles, arrows, and a paragraph on the back of each one".

    And, Yes Sir, one of the sides to all this is a couple (maybe three) articles on the subject for SSC.  Not 100% sure when I'll get to that because I have to finish the presentation first and foremost.  Another "side goal" is (possibly) turning it and a couple of additional related subjects into a PreCon so I can afford to get to your SQL Saturday (definitely on my bucket list) and maybe a presentation for the PASS Summit (the only way that I can come close to affording such a thing because I'm just a regular Joe with no sponsors). πŸ˜‰

    There isn't any chance of you having that all ready for our SQL Saturday is there?  We do have one precon lined up for the Friday before with Kevin Cline.
    What does it take to get a remote speaker like Paul Randal? And I am talking technically so I can do some research to see if we might be able to do that with our Users Group.

  • Lynn Pettis - Thursday, January 18, 2018 8:26 PM

    Jeff Moden - Thursday, January 18, 2018 5:16 PM

    Lynn Pettis - Thursday, January 18, 2018 9:01 AM

    Jeff, Kevin Tate was doing a SQL Server Indexing 101 at our user group meeting last night.  When index maintenance came up I asked if he had read any of the posts where you commented that you needed to go beyond index fragmentation when looking at index reorgs/rebuilds, he hadn't.  Is there a possibility that you may be working on an article or three on what you have been finding in the near future?  There are some of us that want to know.

    Awesome... thanks for the continued encouragement, ol' friend.

    For starters, I'm working on the presentation on the subject that I'm going to give my user group.  I expect it to take nearly 2 hours and I have to make sure my ducks are lined up.  Ed Wagner and I have done a reboot of the "SPID" user group (SQL PASS In Detroit) and we didn't want to have to sweat finding speakers every month.  At the same time, I had this "plan" to cover my now more than 2 year experiment of not doing any index maintenance on my production boxes and wanted to also explain how that notion got started.

    I did a presentation on CROSS TABS and PIVOTS using a 12 million row table (about a million rows per month) and took them through a bunch of optimization techniques ending with why you might want to build an NCI with a duplication of the keys of the clustered index to quickly isolate and aggregate a month's worth of data (million rows) using a CROSS TAB or PIVOT in less than 600 milliseconds.  Think of it as the first introduction to the true power that can be realized from proper indexing along with a little "Divide'n'Conquer".

    Then, Ed Wagner gave a fabulous talk on indexing that he derived from the PreCon that he and I did for Pittsburgh in October of 2016 to further demonstrate the power of indexes and how the wrong indexes can actually kill performance worse than if you had no indexes, etc, etc.

    From there, we really lucked out to continue the "Index" theme.  Mr. Brent Ozar has agreed to come to Michigan in February to do his presentation on why regular index maintenance based on logical fragmentation (which almost everyone does) can be (and was for Ed and I both) a total waste of time.  In April, Mr. Paul Randal is doing a remote presentation on the subject of indexing where he also talks about the "other kind" of index fragmentation (don't want to cough up any spoilers on that if you've not seen it before).  In May, I'm going to stitch it all together with a case study on my 2 year experiment and some test code that demonstrates what happens to an index over a period of a year (measured every hour for 10 hours per day) both with and without index maintenance, the fallacy of using REORGANIZE, how to auto-magically pick the "best" FILL FACTORs (by index) if you insist on index maintenance and why, the fact that most people are defragging after the most damage is already done, how to identify indexes that actually DO benefit from defragging, etc, etc, etc, all in a very "Alice's Restaurant Fashion" with charts and graphs "with circles, arrows, and a paragraph on the back of each one".

    And, Yes Sir, one of the sides to all this is a couple (maybe three) articles on the subject for SSC.  Not 100% sure when I'll get to that because I have to finish the presentation first and foremost.  Another "side goal" is (possibly) turning it and a couple of additional related subjects into a PreCon so I can afford to get to your SQL Saturday (definitely on my bucket list) and maybe a presentation for the PASS Summit (the only way that I can come close to affording such a thing because I'm just a regular Joe with no sponsors). πŸ˜‰

    There isn't any chance of you having that all ready for our SQL Saturday is there?  We do have one precon lined up for the Friday before with Kevin Cline.
    What does it take to get a remote speaker like Paul Randal? And I am talking technically so I can do some research to see if we might be able to do that with our Users Group.

    Damn... I didn't realize your SQL Saturday was on March 24th.  Very sadly, I'm pretty sure that I can't have a precon ready by then, Lynn.  There's a ton left to do just for the 2 hour presentation that I'm working on.

    As for Paul Randal's group, send them an email and ask them if they'd be willing to do a remote for you.  That's what I did.  He advertised it on his site back in November/December.  I don't know what kind of spots he or his group still has open but the answer is always "No" unless you ask.  Maybe send an email to Brent and his group, as well.  Ed might have landed Brian Kelly for a remote on SQL Security (Brian is pretty busy so we're not sure yet).  There are some good folks out there if you don't mind live remotes.  I can also offer a couple of sessions myself but they, of course, would also have to be live remotes.  Once I get the index presentation I'm talking about done, I'll be sure to give you a jingle.  I do want to try it out on my own group first.  That would be in the second week of May.  I can also put you in touch with George Squillace (pronounced "squil-a-chi") and Ed Wagner might also be willing to do a remote for you folks.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)
    Intro to Tally Tables and Functions

  • Jeff Moden - Thursday, January 18, 2018 5:16 PM

    Lynn Pettis - Thursday, January 18, 2018 9:01 AM

    Jeff, Kevin Tate was doing a SQL Server Indexing 101 at our user group meeting last night.  When index maintenance came up I asked if he had read any of the posts where you commented that you needed to go beyond index fragmentation when looking at index reorgs/rebuilds, he hadn't.  Is there a possibility that you may be working on an article or three on what you have been finding in the near future?  There are some of us that want to know.

    Awesome... thanks for the continued encouragement, ol' friend.

    For starters, I'm working on the presentation on the subject that I'm going to give my user group.  I expect it to take nearly 2 hours and I have to make sure my ducks are lined up.  Ed Wagner and I have done a reboot of the "SPID" user group (SQL PASS In Detroit) and we didn't want to have to sweat finding speakers every month.  At the same time, I had this "plan" to cover my now more than 2 year experiment of not doing any index maintenance on my production boxes and wanted to also explain how that notion got started.

    I did a presentation on CROSS TABS and PIVOTS using a 12 million row table (about a million rows per month) and took them through a bunch of optimization techniques ending with why you might want to build an NCI with a duplication of the keys of the clustered index to quickly isolate and aggregate a month's worth of data (million rows) using a CROSS TAB or PIVOT in less than 600 milliseconds.  Think of it as the first introduction to the true power that can be realized from proper indexing along with a little "Divide'n'Conquer".

    Then, Ed Wagner gave a fabulous talk on indexing that he derived from the PreCon that he and I did for Pittsburgh in October of 2016 to further demonstrate the power of indexes and how the wrong indexes can actually kill performance worse than if you had no indexes, etc, etc.

    From there, we really lucked out to continue the "Index" theme.  Mr. Brent Ozar has agreed to come to Michigan in February to do his presentation on why regular index maintenance based on logical fragmentation (which almost everyone does) can be (and was for Ed and I both) a total waste of time.  In April, Mr. Paul Randal is doing a remote presentation on the subject of indexing where he also talks about the "other kind" of index fragmentation (don't want to cough up any spoilers on that if you've not seen it before).  In May, I'm going to stitch it all together with a case study on my 2 year experiment and some test code that demonstrates what happens to an index over a period of a year (measured every hour for 10 hours per day) both with and without index maintenance, the fallacy of using REORGANIZE, how to auto-magically pick the "best" FILL FACTORs (by index) if you insist on index maintenance and why, the fact that most people are defragging after the most damage is already done, how to identify indexes that actually DO benefit from defragging, etc, etc, etc, all in a very "Alice's Restaurant Fashion" with charts and graphs "with circles, arrows, and a paragraph on the back of each one".

    And, Yes Sir, one of the sides to all this is a couple (maybe three) articles on the subject for SSC.  Not 100% sure when I'll get to that because I have to finish the presentation first and foremost.  Another "side goal" is (possibly) turning it and a couple of additional related subjects into a PreCon so I can afford to get to your SQL Saturday (definitely on my bucket list) and maybe a presentation for the PASS Summit (the only way that I can come close to affording such a thing because I'm just a regular Joe with no sponsors). πŸ˜‰

    May huh? Do you allow guests into your user group?

    β€œWrite the query the simplest way. If through testing it becomes clear that the performance is inadequate, consider alternative query forms.” - Gail Shaw

    For fast, accurate and documented assistance in answering your questions, please read this article.
    Understanding and using APPLY, (I) and (II) Paul White
    Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden

  • Jeff Moden - Thursday, January 18, 2018 4:35 PM

    Steve Jones - SSC Editor - Thursday, January 18, 2018 10:53 AM

    Jeff Moden - Thursday, January 18, 2018 8:00 AM

    Yep... and it's not just cookies, either.  They use a thing called "spotlight pixels" which doesn't need cookies.

    Shifting gears, I'm really pissed at some of the recruiter's web sites.  I'm not sure how they do it but I saw an interesting job posting (I'm not looking for a new job... just interested in what people post for job descriptions) and visited the web site to read the rest.  For the next 3 days, some recruiter from that company kept sending me emails that said they saw me look at the job and did I have any questions.  I've run into such a thing many times now.  Although I don't like what folks have to do to become GDPR compliant, I can definitely see why a whole lot of consumers want it.  I think I'll buy an IOT toilet so that I can express my opinion to these recruiters in a manner more faithful to my true feelings. πŸ˜‰

    Recruiting is a tough business. Like selling cars. IT's a numbers game and being pushy pays off. Being passive gets to fired.

    The GDPR will be interesting.  If you engage with someone, you've created a business relationship, so it's not like someone can just say stop. You have to terminate the relationship, and then they have 30 days to respond. It's not quite what many people think, especially with the right to be forgotten. That's not easy, and it's mostly for public stuff. Private records, like sales, will still remain.

    Understood... but I didn't give the buggers my email address.  I just visited the site.

    It is not uncommon for companies to automatically capture all website visits and mark them as "suspects" or "prospects" in the CRM system, with appropriate actions to the salespeople to follow up.
    The only thing they can get directly from tracking the website is (as far as I know) your IP address. But there are methods to cross-correlate that to other information. For instance, most people have a fixed IP address; as soon as you enter your email somewhere it can be correlated to the IP for later visits. There are also public databases that map an IP address to a location on the earth.

    Privacy is mostly an illusion nowadays.


    Hugo Kornelis, SQL Server/Data Platform MVP (2006-2016)
    Visit my SQL Server blog: https://sqlserverfast.com/blog/
    SQL Server Execution Plan Reference: https://sqlserverfast.com/epr/

  • Jeff Moden - Thursday, January 18, 2018 5:16 PM

    Lynn Pettis - Thursday, January 18, 2018 9:01 AM

    Jeff, Kevin Tate was doing a SQL Server Indexing 101 at our user group meeting last night.  When index maintenance came up I asked if he had read any of the posts where you commented that you needed to go beyond index fragmentation when looking at index reorgs/rebuilds, he hadn't.  Is there a possibility that you may be working on an article or three on what you have been finding in the near future?  There are some of us that want to know.

    Awesome... thanks for the continued encouragement, ol' friend.

    For starters, I'm working on the presentation on the subject that I'm going to give my user group.  I expect it to take nearly 2 hours and I have to make sure my ducks are lined up.  Ed Wagner and I have done a reboot of the "SPID" user group (SQL PASS In Detroit) and we didn't want to have to sweat finding speakers every month.  At the same time, I had this "plan" to cover my now more than 2 year experiment of not doing any index maintenance on my production boxes and wanted to also explain how that notion got started.

    I did a presentation on CROSS TABS and PIVOTS using a 12 million row table (about a million rows per month) and took them through a bunch of optimization techniques ending with why you might want to build an NCI with a duplication of the keys of the clustered index to quickly isolate and aggregate a month's worth of data (million rows) using a CROSS TAB or PIVOT in less than 600 milliseconds.  Think of it as the first introduction to the true power that can be realized from proper indexing along with a little "Divide'n'Conquer".

    Then, Ed Wagner gave a fabulous talk on indexing that he derived from the PreCon that he and I did for Pittsburgh in October of 2016 to further demonstrate the power of indexes and how the wrong indexes can actually kill performance worse than if you had no indexes, etc, etc.

    From there, we really lucked out to continue the "Index" theme.  Mr. Brent Ozar has agreed to come to Michigan in February to do his presentation on why regular index maintenance based on logical fragmentation (which almost everyone does) can be (and was for Ed and I both) a total waste of time.  In April, Mr. Paul Randal is doing a remote presentation on the subject of indexing where he also talks about the "other kind" of index fragmentation (don't want to cough up any spoilers on that if you've not seen it before).  In May, I'm going to stitch it all together with a case study on my 2 year experiment and some test code that demonstrates what happens to an index over a period of a year (measured every hour for 10 hours per day) both with and without index maintenance, the fallacy of using REORGANIZE, how to auto-magically pick the "best" FILL FACTORs (by index) if you insist on index maintenance and why, the fact that most people are defragging after the most damage is already done, how to identify indexes that actually DO benefit from defragging, etc, etc, etc, all in a very "Alice's Restaurant Fashion" with charts and graphs "with circles, arrows, and a paragraph on the back of each one".

    And, Yes Sir, one of the sides to all this is a couple (maybe three) articles on the subject for SSC.  Not 100% sure when I'll get to that because I have to finish the presentation first and foremost.  Another "side goal" is (possibly) turning it and a couple of additional related subjects into a PreCon so I can afford to get to your SQL Saturday (definitely on my bucket list) and maybe a presentation for the PASS Summit (the only way that I can come close to affording such a thing because I'm just a regular Joe with no sponsors). πŸ˜‰

    Well, I know I'm going.

  • ChrisM@Work - Friday, January 19, 2018 2:15 AM

    Jeff Moden - Thursday, January 18, 2018 5:16 PM

    Lynn Pettis - Thursday, January 18, 2018 9:01 AM

    Jeff, Kevin Tate was doing a SQL Server Indexing 101 at our user group meeting last night.  When index maintenance came up I asked if he had read any of the posts where you commented that you needed to go beyond index fragmentation when looking at index reorgs/rebuilds, he hadn't.  Is there a possibility that you may be working on an article or three on what you have been finding in the near future?  There are some of us that want to know.

    [/quote]

    Awesome... thanks for the continued encouragement, ol' friend.

    For starters, I'm working on the presentation on the subject that I'm going to give my user group.  I expect it to take nearly 2 hours and I have to make sure my ducks are lined up.  Ed Wagner and I have done a reboot of the "SPID" user group (SQL PASS In Detroit) and we didn't want to have to sweat finding speakers every month.  At the same time, I had this "plan" to cover my now more than 2 year experiment of not doing any index maintenance on my production boxes and wanted to also explain how that notion got started.

    I did a presentation on CROSS TABS and PIVOTS using a 12 million row table (about a million rows per month) and took them through a bunch of optimization techniques ending with why you might want to build an NCI with a duplication of the keys of the clustered index to quickly isolate and aggregate a month's worth of data (million rows) using a CROSS TAB or PIVOT in less than 600 milliseconds.  Think of it as the first introduction to the true power that can be realized from proper indexing along with a little "Divide'n'Conquer".

    Then, Ed Wagner gave a fabulous talk on indexing that he derived from the PreCon that he and I did for Pittsburgh in October of 2016 to further demonstrate the power of indexes and how the wrong indexes can actually kill performance worse than if you had no indexes, etc, etc.

    From there, we really lucked out to continue the "Index" theme.  Mr. Brent Ozar has agreed to come to Michigan in February to do his presentation on why regular index maintenance based on logical fragmentation (which almost everyone does) can be (and was for Ed and I both) a total waste of time.  In April, Mr. Paul Randal is doing a remote presentation on the subject of indexing where he also talks about the "other kind" of index fragmentation (don't want to cough up any spoilers on that if you've not seen it before).  In May, I'm going to stitch it all together with a case study on my 2 year experiment and some test code that demonstrates what happens to an index over a period of a year (measured every hour for 10 hours per day) both with and without index maintenance, the fallacy of using REORGANIZE, how to auto-magically pick the "best" FILL FACTORs (by index) if you insist on index maintenance and why, the fact that most people are defragging after the most damage is already done, how to identify indexes that actually DO benefit from defragging, etc, etc, etc, all in a very "Alice's Restaurant Fashion" with charts and graphs "with circles, arrows, and a paragraph on the back of each one".

    And, Yes Sir, one of the sides to all this is a couple (maybe three) articles on the subject for SSC.  Not 100% sure when I'll get to that because I have to finish the presentation first and foremost.  Another "side goal" is (possibly) turning it and a couple of additional related subjects into a PreCon so I can afford to get to your SQL Saturday (definitely on my bucket list) and maybe a presentation for the PASS Summit (the only way that I can come close to affording such a thing because I'm just a regular Joe with no sponsors). πŸ˜‰

    [/quote]

    May huh? Do you allow guests into your user group?

    [/quote]

    Absolutely we allow guests and it would be great to meet you in person.  That's quite a trip.  Are you going to be in the US in May?

  • Ed Wagner - Friday, January 19, 2018 6:01 AM

    ChrisM@Work - Friday, January 19, 2018 2:15 AM

    Jeff Moden - Thursday, January 18, 2018 5:16 PM

    Lynn Pettis - Thursday, January 18, 2018 9:01 AM

    Jeff, Kevin Tate was doing a SQL Server Indexing 101 at our user group meeting last night.  When index maintenance came up I asked if he had read any of the posts where you commented that you needed to go beyond index fragmentation when looking at index reorgs/rebuilds, he hadn't.  Is there a possibility that you may be working on an article or three on what you have been finding in the near future?  There are some of us that want to know.

    Awesome... thanks for the continued encouragement, ol' friend.

    For starters, I'm working on the presentation on the subject that I'm going to give my user group.  I expect it to take nearly 2 hours and I have to make sure my ducks are lined up.  Ed Wagner and I have done a reboot of the "SPID" user group (SQL PASS In Detroit) and we didn't want to have to sweat finding speakers every month.  At the same time, I had this "plan" to cover my now more than 2 year experiment of not doing any index maintenance on my production boxes and wanted to also explain how that notion got started.

    I did a presentation on CROSS TABS and PIVOTS using a 12 million row table (about a million rows per month) and took them through a bunch of optimization techniques ending with why you might want to build an NCI with a duplication of the keys of the clustered index to quickly isolate and aggregate a month's worth of data (million rows) using a CROSS TAB or PIVOT in less than 600 milliseconds.  Think of it as the first introduction to the true power that can be realized from proper indexing along with a little "Divide'n'Conquer".

    Then, Ed Wagner gave a fabulous talk on indexing that he derived from the PreCon that he and I did for Pittsburgh in October of 2016 to further demonstrate the power of indexes and how the wrong indexes can actually kill performance worse than if you had no indexes, etc, etc.

    From there, we really lucked out to continue the "Index" theme.  Mr. Brent Ozar has agreed to come to Michigan in February to do his presentation on why regular index maintenance based on logical fragmentation (which almost everyone does) can be (and was for Ed and I both) a total waste of time.  In April, Mr. Paul Randal is doing a remote presentation on the subject of indexing where he also talks about the "other kind" of index fragmentation (don't want to cough up any spoilers on that if you've not seen it before).  In May, I'm going to stitch it all together with a case study on my 2 year experiment and some test code that demonstrates what happens to an index over a period of a year (measured every hour for 10 hours per day) both with and without index maintenance, the fallacy of using REORGANIZE, how to auto-magically pick the "best" FILL FACTORs (by index) if you insist on index maintenance and why, the fact that most people are defragging after the most damage is already done, how to identify indexes that actually DO benefit from defragging, etc, etc, etc, all in a very "Alice's Restaurant Fashion" with charts and graphs "with circles, arrows, and a paragraph on the back of each one".

    And, Yes Sir, one of the sides to all this is a couple (maybe three) articles on the subject for SSC.  Not 100% sure when I'll get to that because I have to finish the presentation first and foremost.  Another "side goal" is (possibly) turning it and a couple of additional related subjects into a PreCon so I can afford to get to your SQL Saturday (definitely on my bucket list) and maybe a presentation for the PASS Summit (the only way that I can come close to affording such a thing because I'm just a regular Joe with no sponsors). πŸ˜‰[/quote]
    May huh? Do you allow guests into your user group?[/quote]
    Absolutely we allow guests and it would be great to meet you in person.  That's quite a trip.  Are you going to be in the US in May?
    [/quote]
    It's my turn to visit an old friend, he's in Miami but your internal flights aren't horrendously expensive. It'd be, for me, the trip of a lifetime to visit you also and hear first-hand your findings. I was planning to go sooner, in between finishing this gig at the end of next month and starting the next one, but I'll willingly change the date for this. Florida will have defrosted by then, too πŸ™‚
    You guys have caused quite a stir here.

    β€œWrite the query the simplest way. If through testing it becomes clear that the performance is inadequate, consider alternative query forms.” - Gail Shaw

    For fast, accurate and documented assistance in answering your questions, please read this article.
    Understanding and using APPLY, (I) and (II) Paul White
    Hidden RBAR: Triangular Joins / The "Numbers" or "Tally" Table: What it is and how it replaces a loop Jeff Moden

  • Hugo Kornelis - Friday, January 19, 2018 3:42 AM

    Jeff Moden - Thursday, January 18, 2018 4:35 PM

    Steve Jones - SSC Editor - Thursday, January 18, 2018 10:53 AM

    Jeff Moden - Thursday, January 18, 2018 8:00 AM

    Yep... and it's not just cookies, either.  They use a thing called "spotlight pixels" which doesn't need cookies.

    Shifting gears, I'm really pissed at some of the recruiter's web sites.  I'm not sure how they do it but I saw an interesting job posting (I'm not looking for a new job... just interested in what people post for job descriptions) and visited the web site to read the rest.  For the next 3 days, some recruiter from that company kept sending me emails that said they saw me look at the job and did I have any questions.  I've run into such a thing many times now.  Although I don't like what folks have to do to become GDPR compliant, I can definitely see why a whole lot of consumers want it.  I think I'll buy an IOT toilet so that I can express my opinion to these recruiters in a manner more faithful to my true feelings. πŸ˜‰

    Recruiting is a tough business. Like selling cars. IT's a numbers game and being pushy pays off. Being passive gets to fired.

    The GDPR will be interesting.  If you engage with someone, you've created a business relationship, so it's not like someone can just say stop. You have to terminate the relationship, and then they have 30 days to respond. It's not quite what many people think, especially with the right to be forgotten. That's not easy, and it's mostly for public stuff. Private records, like sales, will still remain.

    Understood... but I didn't give the buggers my email address.  I just visited the site.

    It is not uncommon for companies to automatically capture all website visits and mark them as "suspects" or "prospects" in the CRM system, with appropriate actions to the salespeople to follow up.
    The only thing they can get directly from tracking the website is (as far as I know) your IP address. But there are methods to cross-correlate that to other information. For instance, most people have a fixed IP address; as soon as you enter your email somewhere it can be correlated to the IP for later visits. There are also public databases that map an IP address to a location on the earth.

    Privacy is mostly an illusion nowadays.

    Heh... any way to do the "Borg" thing and "rotate shield frequencies" (IP Addresses)?

    The key here is that I think it's terribly presumptuous (to the point of being rude) to interpret a visit to a website as implied authorization to contact me.  It's as bad as the damned popup ads that think I'm in the market to buy a Lexus just because I visited a site wanting to know a bit more about their technology.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)
    Intro to Tally Tables and Functions

  • ChrisM@Work - Friday, January 19, 2018 6:26 AM

    Ed Wagner - Friday, January 19, 2018 6:01 AM

    ChrisM@Work - Friday, January 19, 2018 2:15 AM

    Jeff Moden - Thursday, January 18, 2018 5:16 PM

    Lynn Pettis - Thursday, January 18, 2018 9:01 AM

    Jeff, Kevin Tate was doing a SQL Server Indexing 101 at our user group meeting last night.  When index maintenance came up I asked if he had read any of the posts where you commented that you needed to go beyond index fragmentation when looking at index reorgs/rebuilds, he hadn't.  Is there a possibility that you may be working on an article or three on what you have been finding in the near future?  There are some of us that want to know.

    Awesome... thanks for the continued encouragement, ol' friend.

    For starters, I'm working on the presentation on the subject that I'm going to give my user group.  I expect it to take nearly 2 hours and I have to make sure my ducks are lined up.  Ed Wagner and I have done a reboot of the "SPID" user group (SQL PASS In Detroit) and we didn't want to have to sweat finding speakers every month.  At the same time, I had this "plan" to cover my now more than 2 year experiment of not doing any index maintenance on my production boxes and wanted to also explain how that notion got started.

    I did a presentation on CROSS TABS and PIVOTS using a 12 million row table (about a million rows per month) and took them through a bunch of optimization techniques ending with why you might want to build an NCI with a duplication of the keys of the clustered index to quickly isolate and aggregate a month's worth of data (million rows) using a CROSS TAB or PIVOT in less than 600 milliseconds.  Think of it as the first introduction to the true power that can be realized from proper indexing along with a little "Divide'n'Conquer".

    Then, Ed Wagner gave a fabulous talk on indexing that he derived from the PreCon that he and I did for Pittsburgh in October of 2016 to further demonstrate the power of indexes and how the wrong indexes can actually kill performance worse than if you had no indexes, etc, etc.

    From there, we really lucked out to continue the "Index" theme.  Mr. Brent Ozar has agreed to come to Michigan in February to do his presentation on why regular index maintenance based on logical fragmentation (which almost everyone does) can be (and was for Ed and I both) a total waste of time.  In April, Mr. Paul Randal is doing a remote presentation on the subject of indexing where he also talks about the "other kind" of index fragmentation (don't want to cough up any spoilers on that if you've not seen it before).  In May, I'm going to stitch it all together with a case study on my 2 year experiment and some test code that demonstrates what happens to an index over a period of a year (measured every hour for 10 hours per day) both with and without index maintenance, the fallacy of using REORGANIZE, how to auto-magically pick the "best" FILL FACTORs (by index) if you insist on index maintenance and why, the fact that most people are defragging after the most damage is already done, how to identify indexes that actually DO benefit from defragging, etc, etc, etc, all in a very "Alice's Restaurant Fashion" with charts and graphs "with circles, arrows, and a paragraph on the back of each one".

    And, Yes Sir, one of the sides to all this is a couple (maybe three) articles on the subject for SSC.  Not 100% sure when I'll get to that because I have to finish the presentation first and foremost.  Another "side goal" is (possibly) turning it and a couple of additional related subjects into a PreCon so I can afford to get to your SQL Saturday (definitely on my bucket list) and maybe a presentation for the PASS Summit (the only way that I can come close to affording such a thing because I'm just a regular Joe with no sponsors). πŸ˜‰

    May huh? Do you allow guests into your user group?[/quote]
    Absolutely we allow guests and it would be great to meet you in person.  That's quite a trip.  Are you going to be in the US in May?
    [/quote]
    It's my turn to visit an old friend, he's in Miami but your internal flights aren't horrendously expensive. It'd be, for me, the trip of a lifetime to visit you also and hear first-hand your findings. I was planning to go sooner, in between finishing this gig at the end of next month and starting the next one, but I'll willingly change the date for this. Florida will have defrosted by then, too πŸ™‚
    You guys have caused quite a stir here.[/quote]
    That would be awesome, Chris.  There's probably no chance of me ever getting to Europe and you're one of the people on my bucket list.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.
    "Change is inevitable... change for the better is not".

    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)
    Intro to Tally Tables and Functions

Viewing 15 posts - 61,006 through 61,020 (of 66,000 total)

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