gianm commented on issue #19408: URL: https://github.com/apache/druid/issues/19408#issuecomment-4385872667
> * If [fix: Erroneous pruning for non-STRING RangeFilter. #19415](https://github.com/apache/druid/pull/19415) blocks the RangeFilter for non-string columns I think secondary timestamps use case may be impacted - it may be common to use them in secondary partition pruning with range filter (at least we have 1 use case). What would be the workaround? To store them as string and then cast if needed e.g. for MILLIS_TO_TIMESTAMP function (and take query performance hit?) or store duplicated column (and take storage space hit?)? I think those would be the two main workarounds. Neither is really ideal so the best thing would be to actually build the feature. > * Any plans to support non-string columns (especially LONG) in secondary partitioning? It has come up a couple times but I am not aware of someone currently working on it. I think it could be done by introducing an optional types field on `DimensionRangeShardSpec`, setting that to the type of the field when we create the shard specs, and then having the filters prune only when their match-type is the same as the field type. (Which will generally be true for SQL unless some schema evolution or casting is happening.) -- 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] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
