После загрузки исходного кода и запуска его в отладчике я обнаружил, что с одной стороны он довольно прост, а с другой ограничен.
Прямая часть заключается в том, что мы просто должны переопределить isPushdownFilterSupported
и pushdownFilter
при реализации интерфейса ConnectorMetadata
.
Ограничительная часть заключается в том, что планировщик запросов теперь считает, что Разъем может иметь дело с любым типом и комбинацией настольных фильтров. В моем случае я хотел бы позаботиться только об этом, поддерживаемый мной удаленный API поддерживает, а Presto позаботится обо всем остальном.
Похоже, что команда Presto полностью осознает это, так как а) методы помечены @Experimental
и б) соответствующими комментариями This interface can be replaced with a connector optimizer rule once the engine supports these (#12546).
Это был бы явно правильный подход для моего варианта использования.
/**
* Experimental: if true, the engine will invoke pushdownFilter instead of getTableLayouts.
*
* This interface can be replaced with a connector optimizer rule once the engine supports these (#12546).
*/
@Experimental
default boolean isPushdownFilterSupported(ConnectorSession session, ConnectorTableHandle tableHandle)
{
return false;
}
/**
* Experimental: returns table layout that encapsulates the given filter.
*
* This interface can be replaced with a connector optimizer rule once the engine supports these (#12546).
*/
@Experimental
default ConnectorPushdownFilterResult pushdownFilter(ConnectorSession session, ConnectorTableHandle tableHandle, RowExpression filter, Optional<ConnectorTableLayoutHandle> currentLayoutHandle)
{
throw new UnsupportedOperationException();
}