Clint Wylie

Thanks for the additional details :+1: >sqlType: One of Druid's scalar data types: `VARCHAR`, `FLOAT`, `DOUBLE` or `BIGINT`. Case-insensitive. How do you plan to support Druid's complex typed columns? (Such...

>thanks for the head's up on the complex types. Can you point me to documentation on the details of the type? To any SQL support we already have? (heh, I...

this still happens when using `remote` for the `druid.indexer.runner.type`, apologies that stalebot closed this issue. I also ran into another issue when performing the same steps with similar outcome (though...

> * No, or reduced, need for server thread pool size and connection pool size tuning. Today the server thread pool sizes on Brokers and data servers, and the Broker-to-data-server...

>We don't have to keep the current request/response structure. If it helps, we can change to a protocol that allows multiplexing of multiple requests over the same connection. Sure, though...

>It's also an option to keep the same request/response protocol at the outer layer, but use a different protocol for the inner layer. In my experience the inner layer (Broker...

Some additional less scientific measurements, using a 10GB file of the nyc taxi dataset with all of the columns stored as strings: grouping performance seems competitive: select * does show...

there aren't any explicit conflicts, but this PR needs updated after #12315 to implement the new methods, i'll try to see if I can consolidate some of the code a...

2.5m rows of data generated with https://github.com/lemire/StarSchemaBenchmark: also (possibly coincidence) the smaller encoding seems to have a small positive effect on ingest task time:

ran taxi set again with mixed types, it gets pretty good improvements from the date/time strings: also sometimes the improvement is not a lot, pretty small overlap in this one: