Thank you for posting the test case.

SQL> create table t1 (
  2    x01 number, x02 number, x03 number, x04 number, x05 number,
  3    x06 number, x07 number, x08 number, x09 number, x10 number,
  4    x11 number, x12 number, x13 number, x14 number, x15 number,
  5    x16 number, x17 number, x18 number, x19 number, x20 number
  6  )
  7  /

Tabelle wurde erstellt.

SQL> insert into t1
  2  select
  3    null, null, null, null, null,
  4    null, null, null, null, null,
  5    null, null, null, null, null,
  6    null, null, null, null, 1
  7  from dual
  8  connect by level <= 1000000;
 
SQL> create table t2 (
  2    x01 number, x02 number, x03 number, x04 number, x05 number,
  3    x06 number, x07 number, x08 number, x09 number, x10 number,
  4    x11 number, x12 number, x13 number, x14 number, x15 number,
  5    x16 number, x17 number, x18 number, x19 number, x20 number
  6  )
  7  /

Tabelle wurde erstellt.

SQL> insert into t2
  2  select
  3    1   , null, null, null, null,
  4    null, null, null, null, null,
  5    null, null, null, null, null,
  6    null, null, null, null, null
  7  from dual
  8  connect by level  <= 1000000;
   
SQL> select sum(x01),sum(x20),count(*) from t1
  2  /

  SUM(X01)   SUM(X20)   COUNT(*)
---------- ---------- ----------
              1000000    1000000

1 Zeile wurde ausgewählt.

SQL> select sum(x01),sum(x20),count(*) from t2
  2  /

  SUM(X01)   SUM(X20)   COUNT(*)
---------- ---------- ----------
   1000000               1000000

1 Zeile wurde ausgewählt.

SQL> select segment_name, blocks,bytes
  2  from user_segments
  3  where segment_name in ('T1','T2')
  4  /

SEGMENT_NAME                       BLOCKS      BYTES
------------------------------ ---------- ----------
T1                                   3840   31457280
T2                                   1664   13631488

2 Zeilen ausgewählt.

That is another excellent point about column position and the effect that NULL values in columns have on storage requirements – that could also be the reason why Oracle only permits adding columns at the end of a table’s column list, as a column with a NULL default value will occupy no additional space in a row piece, thus eliminating or delaying row chaining and/or row migration when a column is added.

Could you verify that table T1′s first column contains a value and that table T2′s last column contains a value? It could just be a typo, but your block counts for the two tables seem to conflict with your first paragraph in your comment (the first paragraph agrees with my understanding and at least one test case on this blog). It would seem that table T2 would require more blocks than table T1 due to T2 having to indicate NULL values in the first 19 columns in the table, while that is not required for the last 19 columns in table T1.

I think that if you supplied your test script in a comment, that would help to add value to this blog article by allowing someone else to reproduce the test.

Thank you for adding the comment about row chaining; the comment certainly adds value to this blog article.

I agree that row chaining should be a third bullet point item (I forgot that you mentioned it in your book). The follow-up article, which should appear on the site Monday, was originally intended to precede this article. The follow-up looks at the effects of row chaining for tables that have up to 1,000 columns. In the follow-up article, the row chaining will be limited to that which happens due to the 255 column per row piece limit, and will not explore row chaining caused by updates of rows.

Another approach to optimal column order is from the storage side, if the table contains empty columns. When they are at the end of the table, the segment requires less blocks, which is nice by itself and of course has an impact on the buffer cache’s efficiency.

My test case includes 2 tables T1 and T2 with 20 columns x01-x20. Both contain 1000000 records. T1′s x01 contains 1, all it’s other columns are null. T2′s x20 contains 1, all it’s other columns are null. On my machine, T1 occupies 3840 blocks while T2 occupies 1664 blocks.

First of all, thank you for referencing my book on that matter.

I would like to point out that, IMO, the column order is also relevant in a third situation. Specifically, for chained rows. In fact, as I wrore at page 537:

“The impact on performance caused by chaining is independent of the access path. In fact, every time the first piece is found, it is necessary to read all the other pieces through the rowid as well. There is one exception, however. As discussed in the section “Optimal Column Order,” when only part of a row is needed, not all pieces may need to be accessed. For example, if only columns stored in the first piece are needed, there is no need to access all other pieces.”

Hence, for rows that are usually chained, it might be sensible to add a new column near the beginning of the row.

Cheers,
Chris