Post reply

Database Compression Settings

  • September 3, 2021 at 12:00 am

    #3917567

    Comments posted to this topic are about the item Database Compression Settings

  • September 3, 2021 at 7:34 am

    #3926551

    tricky as based on the way it was phrased there are 2 right answers

  • September 3, 2021 at 9:12 am

    #3926584

    frederico_fonseca wrote:

    tricky as based on the way it was phrased there are 2 right answers

    I agree.  There's an implication in the question that caught me out.

    On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" ... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
    —Charles Babbage, Passages from the Life of a Philosopher

    How to post a question to get the most help http://www.sqlservercentral.com/articles/Best+Practices/61537

  • September 3, 2021 at 2:52 pm

    #3926687

    What's tricky here? The "ensure"

    The comments don't really explain what you mean.

  • September 3, 2021 at 4:34 pm

    #3926719

    Agreed. The "ensure" would dictate at all times which would be inclusive of anyone creating an index. There is no way to "ensure" the omission of the compression parameter for the index creation therefor, there is no way to "ensure" it happens. Very tricky question.

  • September 6, 2021 at 6:43 am

    #3927093

    Steve Jones - SSC Editor wrote:

    What's tricky here? The "ensure"

    The comments don't really explain what you mean.

    I  was trying to be a bit circumspect to avoid giving away the answer so it's fair enough to say that I didn't explain what I meant.  The phrasing, "I want to ensure that all indexes in any database", suggests you're looking for a global setting.   One of the answers is "There is no way to compress all indexes in a database" so I don't think it's unreasonable to see this as a correct answer because it's not actually possible.  The only way to compress an index is to specify the option when the individual index is created.  All things being equal, having to do something 'manually' every time it's required is a surefire way to ensure it doesn't happen for all indexes. It is, of course, the correct and only way to do it but I think there's a definite red-herring in the answers.

    • This reply was modified 3 years, 3 months ago by  Neil Burton. Reason: Edited for clarity

    On two occasions I have been asked, "Pray, Mr. Babbage, if you put into the machine wrong figures, will the right answers come out?" ... I am not able rightly to apprehend the kind of confusion of ideas that could provoke such a question.
    —Charles Babbage, Passages from the Life of a Philosopher

    How to post a question to get the most help http://www.sqlservercentral.com/articles/Best+Practices/61537

  • September 6, 2021 at 3:30 pm

    #3927232

    I can see that. I do try to make somewhat plausible questions and choices to get people to think.

    I added the "all future indexes" change to make this more of a default item.

  • September 7, 2021 at 5:14 am

    #3927396

    I believe that I'd have to bring the newly constructed 4 banded pork chop launcher into play if anyone did such a thing because there ae a huge number of gotcha's including but not limited the fact that rebuilding compressed intakes takes about 3 times as long and uncompressed indexes.

    --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)

Viewing 8 posts - 1 through 7 (of 7 total)

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