[
https://issues.apache.org/jira/browse/PARQUET-1064?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16267688#comment-16267688
]
Ryan Blue commented on PARQUET-1064:
------------------------------------
I don't have an opinion either way. I would have left out the sort order for
interval (and int96) because it is useless, but then we would have a confusing
situation where some types don't have an ordering. So instead, I just went with
the ordering that we were already using: byte-wise signed comparison. In
Parquet MR, I think we should not produce or read statistics for these types.
Then it doesn't matter what the type's ordering is.
> Deprecate type-defined sort ordering for INTERVAL type
> ------------------------------------------------------
>
> Key: PARQUET-1064
> URL: https://issues.apache.org/jira/browse/PARQUET-1064
> Project: Parquet
> Issue Type: Bug
> Reporter: Zoltan Ivanfi
> Assignee: Zoltan Ivanfi
> Priority: Minor
>
> [LogicalTypes.md in
> parquet-format|https://github.com/apache/parquet-format/blob/master/LogicalTypes.md]
> defines the the sort order for INTERVAL to be produced by sorting by the
> value of months, then days, then milliseconds with unsigned comparison.
> According to these rules, 1d0h0s > 0d48h0s, which is counter-intuitive and
> does not seem to have any practical uses. Unless somebody is aware of an
> actual use-case in which this makes sense, I think the sort order should be
> undefined instead. The [reference implementation in
> parquet-mr|https://github.com/apache/parquet-mr/blob/352b906996f392030bfd53b93e3cf4adb78d1a55/parquet-hadoop/src/main/java/org/apache/parquet/format/converter/ParquetMetadataConverter.java#L459]
> already considers the ordering to be unknown.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
