knudsen,

Сталкивался с тем, что при таком раскладе бывает оптимизатор не может корректно оценить мощность результата, возвращаемого ф-ей токенизации, и сильно промахивается с планом, если сверху что-либо сложное навёрнуто.

В z/OS есть возможность дать оценку CRADINALITY при создании табличной функции и/или указать её в ф-ии TABLE(), а вот в DB2 for LUW - как-то "забыли" (хотя я не вижу причин, почему).
Эффективных методов так или иначе дать знать оптимизатору, что там будет, с ходу не нашёл, хотя глубоко вопрос не изучал.