Return to Answer

Just throwing out a few suggestions here as to why Microsoft would do this:

1. They have geared their default to be best possible OLAP performance (less page reads with a fill factor of 0/100)
2. They are assuming that INSERTed data will most likely be at the end of the table, making the extra space per page useless
3. They are assuming that typically UPDATEd data will not lengthen row data very often, causing a page split

This is just guessing here. The only people that can really answer that question accurate is the SQL Server team themselves.

Just throwing out a few suggestions here as to why Microsoft would do this:

1. They have geared their default to be best possible OLAP performance (less page reads with a fill factor of 0/100)
2. They are assuming that INSERTed data will most likely be at the end of the table, making the extra space per page useless
3. They are assuming that typically UPDATEd data will not lengthen row data very often, causing a page split

This is just guessing here. The only people that can really answer that question accurately is the SQL Server team themselves.

Just throwing out a few suggestions here as to why Microsoft would do this:

1. They have geared their default to be best possible OLAP performance (less page reads with a fill factor of 0/100)
2. They are assuming that INSERTed data will most likely be at the end of the table, making the extra space per page useless
3. They are assuming that typically UPDATEed data will not lengthen row data very often, causing a page split

This is just guessing here. The only people that can really answer that question accurate is the SQL Server team themselves.

Just throwing out a few suggestions here as to why Microsoft would do this:

1. They have geared their default to be best possible OLAP performance (less page reads with a fill factor of 0/100)
2. They are assuming that INSERTed data will most likely be at the end of the table, making the extra space per page useless
3. They are assuming that typically UPDATEd data will not lengthen row data very often, causing a page split

This is just guessing here. The only people that can really answer that question accurate is the SQL Server team themselves.

Just throwing out a few suggestions here as to why Microsoft would do this:

1. The have geared their default to be best possible OLAP performance (less page reads with a fill factor of 0/100)
2. They are assuming that INSERTed data will most likely be at the end of the table, making the extra space per page useless
3. They are assuming that typically UPDATEed data will not lengthen row data very often, causing a page split

This is just guessing here. The only people that can really answer that question accurate is the SQL Server team themselves.

Just throwing out a few suggestions here as to why Microsoft would do this:

1. They have geared their default to be best possible OLAP performance (less page reads with a fill factor of 0/100)
2. They are assuming that INSERTed data will most likely be at the end of the table, making the extra space per page useless
3. They are assuming that typically UPDATEed data will not lengthen row data very often, causing a page split

This is just guessing here. The only people that can really answer that question accurate is the SQL Server team themselves.