This message was deleted.
# generals
Slackbot
10/19/2023, 10:48 AMThis message was deleted.
l
Laksh Singla
10/19/2023, 10:49 AMThis assumption won’t hold true in many cases and specifying explicit order by is important. For example, if there are multiple segments, and the query merges data from those segments, then the order might be different.
Laksh Singla
10/19/2023, 10:51 AMLaksh Singla
10/19/2023, 10:51 AMSpecifies some internals when you order by time on scan
l
lnault
10/19/2023, 10:51 AMoh, ok, so it is only true for datas on the same segment ?
l
Laksh Singla
10/19/2023, 10:52 AMI don’t think there are any guarantees built for this.
Laksh Singla
10/19/2023, 10:53 AMso relying on this would be incorrect
Laksh Singla
10/19/2023, 10:53 AMif there’s multiple threads involved, I’d assume that it will break for a single segment as well, with complex queries (other than scans)
l
lnault
10/19/2023, 10:54 AMfine. Thanks ! So it is like what we can have in other databases, like postgres, where same queries returns usually the results in same order if you run them many times, but with no garantees.
lnault
10/19/2023, 10:55 AMThanks, it is more clear !
j
John Kowtko
10/19/2023, 4:00 PMSQL in general will not guarantee any ordering of the data returned unless an ORDER BY clause is specified ...
So as Laksh says, you cannot rely on "incidental" behavior here ... (edited)
👍 1