vlsi commented on PR #5284: URL: https://github.com/apache/calcite/pull/5284#issuecomment-6342314780
Thanks for the measurements. The benchmark shows no measurable change in time, since the confidence intervals overlap, and allocation drops by 1.3–2.5% only on an IN list of 100,000 to 1,000,000 string literals. On ordinary queries the difference would be lost in noise. The price is two new public overloads of `NlsString.asSql` that we would have to maintain, one of them with a `suffix` parameter that has no effect. I suggest closing this PR, and CALCITE-7810 with it, and focusing on the other sub-tasks of CALCITE-7805, which account for most of the allocation you measured. Could you also explain why Druid does not pass a large list of IDs to Calcite as a single array value? Even an array bound to a `?` parameter is expanded by Druid's `SqlParameterizerShuttle#createArrayLiteral` into `ARRAY[...]` with one `SqlLiteral` per element, so planning still processes a million literals. A `RexDynamicParam` has a constant-size digest and needs no per-element validation or type inference. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
