This message was deleted.

I am definitely not an expert in this, but I looked at the code a bit and it seems to me that this is not related to the number of parameters. I think it may be a bug related to the function definition here where the parameter expects a literal value: https://github.com/apache/druid/blob/fb38085ddbb439974325b230739e129ebcbf9ba1/exte[…]hes/quantiles/sql/DoublesSketchApproxQuantileSqlAggregator.java but like I said, I am not an expert, I may be misreading how calcite interprets

OperandTypes.LITERAL

.

Nope, even Literal value in template did not work. I noticed that when I try the following directly via query UI of druid

SELECT APPROX_QUANTILE_DS( "duration" , CAST(0.99 as DOUBLE)) as p99 ...

I get

Error: Plan validation failed

org.apache.calcite.runtime.CalciteContextException: From line 13, column 8 to line 13, column 61: Cannot apply 'APPROX_QUANTILE_DS' to arguments of type 'APPROX_QUANTILE_DS(<BIGINT>, <DOUBLE>)'. Supported form(s): 'APPROX_QUANTILE_DS(column, probability)' 'APPROX_QUANTILE_DS(column, probability, k)'

org.apache.calcite.tools.ValidationException

Looks like somewhere there is an implicit type conversion and it does not like double value

Interesting... what happens if you don't cast it, just

0.99

?

Then it works,

SELECT APPROX_QUANTILE_DS( "duration", 0.99)

is valid.

So, it essentially doesn't like expressions for the parameter... I think this is a bug. I will investigate further and create a github issue to track this.

PR for this: https://github.com/apache/druid/pull/14249 The issue is that this parameter must be a literal. We eliminate CASTs around literals, but CAST elimination happens after operator validation. So, at the point the operator args are checked, the CAST is still there and validation fails. The PR adjusts validation to accept literals wrapped in CAST (since they'll be eliminated later anyway)