However that function does timestamp validation and potentially slows down queries and prevents other optimizations (for example what @adriangb is doing in #15301)

I'm very curious about why this optimization is being blocked.

take

However that function does timestamp validation and potentially slows down queries and prevents other optimizations (for example what @adriangb is doing in #15301)

I'm very curious about why this optimization is being blocked.

I think it is because we don't have the analysis to translate the min(to_timestamp_seconds(column)) into a column < [current topk min heap value]

I think it is because we don't have the analysis to translate the min(to_timestamp_seconds(column)) into a column < [current topk min heap value]

1. So, should this situation be optimized as well?

2. I looked at the EventTime field in the hits dataset and found nothing special about it other than that it’s of type int64. I’m not quite sure why ORDER BY to_timestamp_seconds("EventTime") is used. I know this function converts the field to the timestamp type, but I don’t understand the significance of doing so.

3. I also saw other statements containing to_timestamp_seconds("EventTime"). Do those statements need to be modified?

Another discrepancy I found in the queries is the "EventDate"::INT::DATE" casting. Is this something we could remove as well? Maybe would be good to look at all further that are applied to the queries and undo them if possible (or file issues when the planner fails to plan them).

Another discrepancy I found in the queries is the "EventDate"::INT::DATE" casting. Is this something we could remove as well? Maybe would be good to look at all further that are applied to the queries and undo them if possible (or file issues when the planner fails to plan them).

• Filed Update ClickBench queries to avoid ::INT::DATE casting #15509