It could be a feature. Nowadays, when having a sorted column could be beneficial for the implementation of an operator, we do a scan of the column to see whether it is sorted. This is then recorded in the column descriptor. Also when we then find out that the column is not sorted, this is also remembered. This means that we don't have to try quite as hard to find out that a column is sorted early on. Of course, if we can logically determine that the result of an operation is sorted, we record that. Given that the implementation of your query first produces a list of positions that indicate in which order the column is sorted and then in a separate operation produces this sorted list, we have lost the knowledge that the result is sorted on the way. But we will find out when we do other operations. On 03/30/2016 05:27 PM, Roberto Cornacchia wrote:
Before filing a bug report, I'd like to ask here whether this is intentional/expected.
sql>create table t(a int); operation successful (0.650ms) sql>insert into t values (1),(0),(3),(2); 4 affected rows (0.638ms) sql> sql>create table sorted_t as select a from t order by a with data; operation successful (0.807ms) sql> sql>select table,column,sorted from sys.storage() where "table"='sorted_t'; +----------+--------+--------+ | table | column | sorted | +==========+========+========+ | sorted_t | a | false | +----------+--------+--------+
I am pretty sure it use to be that the sorting used in a "CREATE TABLE AS ... WITH DATA" would result in the tsorted property to be true for the (first) sorted column.
Now this isn't the case. Is that a bug or a feature?
Roberto
_______________________________________________ users-list mailing list users-list@monetdb.org https://www.monetdb.org/mailman/listinfo/users-list
-- Sjoerd Mullender