Vukasin Milovanovic
Vukasin Milovanovic
@gpucibot merge
cuDF does not have a map type, so such columns are read as a list of structs of key-value pairs. AFAICT the behavior here is expected.
That's how the structs are formatted; '0' and '1' are auto generated field names in the struct column. CC @galipremsagar in case I'm missing something related to formatting.
I got some ideas, but they depend on a few points I'm not sure about yet: 1. Are comparison semantics of `byte_array_view` similar/equivalent to `string_view`? 2. Is `byte_array_view` a `device_span`?...
Aiming to avoid code duplication: `ordered_device_span`: public device_span` + comparison impl `string_view` : derived from `ordered_device_span` + min/max impl `byte_array_view` : derived from `ordered_device_span` + min/max impl ~Probably requires CRTP...
Didn't know about libcu++ potential involvement. In that case, my vote is to publicly derive from `device_span` to remove duplicated data access members (FWIW). Much less exciting solution :D
Note: any PRs that change benchmarks are encouraged/required to migrate the benchmarks to NVBench.
Note: any PRs that change benchmarks are encouraged/required to migrate the benchmarks to NVBench.
> This is a blocker for Spark to be able to use the JSON reader. Because we do not know all of the columns, the user just gives the ones...
I'm asking as a short term solution, because column pruning would need to be reworked when we add nested type support. Does this feature request include pruning of nested columns...