Surprisingly, MySql doesn't flag it. Try this bogus query " SELECT CustomerName, sum(customerId) FROM Customers;" here -- https://www.w3schools.com/sql/trysql.asp?filename=trysql_select_all

so I noticed that whenever we use timeConvert or other similar function in aggregation clause it always has some issue

for example I do something like

SELECT  timeConvert(ts, 'SECONDS', 'DAYS') FROM table LIMIT 100;

it shows error as

message: PQLParsingError: org.apache.pinot.pql.parsers.Pql2CompilationException: Aggregation
function expects exact 1 argument
at org.apache.pinot.pql.parsers.pql2.ast.FunctionCallAstNode.buildAggregationInfo(FunctionCallAstNode.java: 86)
at org.apache.pinot.pql.parsers.pql2.ast.OutputColumnAstNode.updateBrokerRequest(OutputColumnAstNode.java: 36)
at org.apache.pinot.pql.parsers.pql2.ast.BaseAstNode.sendBrokerRequestUpdateToChildren(BaseAstNode.java: 78)
at org.apache.pinot.pql.parsers.pql2.ast.OutputColumnListAstNode.updateBrokerRequest(OutputColumnListAstNode.java: 45)
at org.apache.pinot.pql.parsers.pql2.ast.BaseAstNode.sendBrokerRequestUpdateToChildren(BaseAstNode.java: 78)
at org.apache.pinot.pql.parsers.pql2.ast.SelectAstNode.updateBrokerRequest(SelectAstNode.java: 118)
at org.apache.pinot.pql.parsers.Pql2Compiler.compileToBrokerRequest(Pql2Compiler.java: 105)
at org.apache.pinot.controller.api.resources.PqlQueryResource.getQueryResponse(PqlQueryResource.java: 104)
at <http://org.apache.pinot.controller.api.resources.PqlQueryResource.post|org.apache.pinot.controller.api.resources.PqlQueryResource.post>(PqlQueryResource.java: 80)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java: 43)
at java.lang.reflect.Method.invoke(Method.java: 498)
at org.glassfish.jersey.server.model.internal.ResourceMethodInvocationHandlerFactory.lambda$static$0(ResourceMethodInvocationHandlerFactory.java: 52))

I also noticed that newer version seems to rework this part of logics

was this limitation is removed?

Are you seeing this with latest code?

And can you give me steps to introduce?

not yet, I can test latest code in a bit

using timeConvert(…) method like in the example above

@User I saw your issue: https://github.com/apache/incubator-pinot/issues/5261

was it done already?

I added some code to support multiple arguments

But that applies to aggregation functions only. Not sure why is that kicking in for timeConvert, as it is not an aggregation

seems like functionCallAstNode got treated as aggregation node in this part of logic: https://github.com/apache/incubator-pinot/blob/master/pinot-common/src/main/java/org/apache/pinot/pql/parsers/pql2/ast/OutputColumnAstNode.java#L43

^^ has not changed in a while. So my guess is that new code exposed an existing bug

seems like this pr should added support for using timeConvert or related method in selection, I can double check to see if we are on that particular version

Also I do not see

function expects exact 1 argument

in the latest code (when grepping)

Is you version recent (as in last 3 weeks or so)?

not really, we are lacking in catching up with master

thanks for all info and I will test out the latest version first

Ok, then likely not related to any of my changes for supporting multiple args

@User We use

AggregationFunctionType.getAggregationFunctionType(String functionName)

to identify whether the function is aggregation or transform. (Called in

FunctionDefinitionRegistry.isAggFunc(String functionName)

)

So with the latest code it should have no issue

New blog post! https://twitter.com/ApachePinot/status/1260603437844217856

hey all, how is horizontal pod autoscaling supposed to behave for pinot-servers? What I observed:

When the server pod is auto scaled, the segments are not reassigned to the new server, running rebalance is required for that.

When the server pods are scaled down, the ideal state still shows the segments on the terminated servers. They are not reassigned to live servers.

yes, rebalance command must be run manually. Automating it is easy, but most of the time users like to control this

The main reason is there are multiple replicas and a server failing is not a problem and Kuberenetes should restart that pod

ok so the observations are inline with how its supposed to work right?

yes