Проблемы с производительностью с JDBC

В настоящее время я сталкиваюсь с проблемой, когда конкретный SQL-запрос занимает около 30 секунд в моем приложении Java, но

В вопросе
Медленный запрос в Java с помощью JDBC, но не в других системах (TOAD) предполагается, что использование PreparedStatement, привязанного к переменным Java, может сделать запрос намного медленнее, чем в SQL-клиент (в данном случае TOAD), потому что Oracle не понимает, какие индексы использовать. Может ли это быть проблемой и с PreparedStatement без параметров?

В чем еще может быть проблема?

Запрос выглядит примерно как

select 
sum(col1),
sum(col2),
max(select ...)
from view_
where time_id = get_time_id(to_date('2010-10-10','yyyy-mm-dd'))

, где view_ - это сложное представление, содержащее агрегаты таблиц и других сложных представлений. Запрос выполняется как PreparedStatement, но без каких-либо параметров. Это не Кажется, имеет значение, используем ли мы подготовленный оператор или просто простые операторы.

Поскольку план выполнения довольно обширен, я не могу опубликовать все, если он здесь, но релевантная разница, похоже, заключается в следующем:

UNION-ALL 
TABLE ACCESS FULL GVC_WH.PLAYER_FACT_DAILY TABLE 37 6717151 596,934.317 19940 240 7621178231 19502 

UNION-ALL 
TABLE ACCESS BY INDEX ROWID GVC_WH.PLAYER_FACT_DAILY TABLE 38 2657 236.120 2429 30 20544658 2428 
INDEX RANGE SCAN GVC_WH.PK_AGG_PLAYER INDEX (UNIQUE) 37 2657 16 1 638743 16 

Где первый фрагмент - это когда он запускается с помощью тонкого клиента JDBC, а второй - когда он запускается внутри SQL Developer. Он не выбирает правильный индекс при запуске в качестве оператора (не имеет значения, использую ли я подготовленный оператор или нет) с тонким клиентом JDBC. Разница во времени составляет 30 секунд для первого и 0,5 секунды для второго.

Может быть, использование функции get_time_id запрещает использование индекса при использовании через JDBC, даже если это не функция для столбца и даже если кажется, что он работает в SQL Developer?