Проблема построения оптимального плана выполнения запроса при использовании коллекций. Применение Extensible Optimizer

Продублирую, что уже в телеграм канале написал:

Целиком коллекцию передавать медленнее, чем обернуть её в пайплайн: http://orasql.org/2017/12/13/collection-iterator-pickler-fetch-pipelined-vs-simple-table-functions/

И ещё есть известная проблема с не работающим jppd с коллекциями: http://orasql.org/2019/05/30/workarounds-for-jppd-with-view-and-tablekokbf-xmltable-or-json_table-functions/

Вообще, проблемы при передаче коллекций через бинды и реальном выполнении - давно нет, т.к. срабатывает bind peeking:
https://timurakhmadeev.wordpress.com/2010/03/09/cardinality-of-table-collection-expression/
Естественно, это не касается explain plan, в котором не может быть bind peeking.

Ну, и гораздо более простой workaround для таких non-pipeline функций: вы можете использовать хинт dynamic_sampling(2), т.е. с дефолтным уровнем 2: https://gist.github.com/xtender/e82ba050e833dc469a41a529f879c603

В целом, резюмируя, такой проблемы особо и нет, т.к.

1. с передачей коллекций через бинды, срабатывает bind_peeking, а 8168 в E-Rows будет только для explain, что в реальной жизни не нужно;

2. использовать non-pipeline функции, возвращающие коллекции неэффективно, как я выше уже показывал;

3. в большинстве случаев при написании запросов с такими функциями программист уже заранее знает какие объемы и планы там планируются, и тут не важна прямо абсолютная точность размера коллекции, а прогнозируемая надежность, т.о. хинт еще и предоставляет дополнительные возможности понять что именно там планировалось и на что рассчитывалось. При этом при тестировании или explain как раз может использовать хинт cardinality для просмотра планов при разных мощностях входного множества;

4. для пайплайн функции - этот подход не сработает, точнее придется сначала получать все из пайплайн функции до конца, чтобы получить кол-во строк, при этом придется использовать больше памяти для буферизации этих строк, т.е. терять эффективность pipeline.