Привет, форумчане!

Предыстория .
"перехожу" с Oracle на DB2.
Данные таблиц Oracle хранит данные в блоках, и в большинстве случаев если мы вставляем строку в таблицу, мы получим данные строки (все колонки которые не LOB) сохранённые в одном блокe.
Все LOB данные помещаются в отдельный space, в tablespace нашей таблицы мы будем иметь лишь референс на LOB.

Проблема .
Предположим что есть таблицы


Предположим что данные по полю F2 нас не интересуют в большинстве случаев.
делаем селект:

В обоих случаях, т.к. Oracle работает с блоками, он поднимет в буфер всё что есть в блоке по строкам: F1(NUMBER) и F2(референс на CLOB или VARCHAR2)

То есть в случае 1 мы имеем в буфере просто ссылку на CLOB которая достаточно мала, а во 2м - сами строковые данные которые до 4000 байтов на строку таблицы. Т.е. в Оракле - смена CLOB на VARCHAR(4000) на перформанс работы DB Cache бы - повлияла существенно.

Вопрос .
Товарищи эксперты, поясните пожалуйста, как это работает в DB2, какой импакт там?

Спасибо.

Всем огромное спасибо за исчерпывающие ответы!
Раз ситуация аналогичная с Oracle, тогда проблема становится более понятной.

Резюмируя :
- поля таблицы можно покрыть индексом (ами) не включая VARCHAR(4000) поле, т.е. избежать обращения к таблице
- про-профилировать запросы чтобы понять реальный импакт (просто запросы еще пишутся), действительно ведь импакт будет ощущаться только в случае массивных выборок и возможно лучшим решением будет использовать VARCHAR(4000) (данные здесь планируются всегда под завязку 4000)
- избегаем преобразования CLOB->VARCHAR в SQL запросах если оставляем CLOB