+1 to Gian's reply. I think some process overall to release minor versions
faster would be very beneficial.
Prashant
On Wed, May 30, 2018 at 1:26 PM Gian Merlino wrote:
> My feeling is that the desire to get out regression fixes like
> https://github.com/druid-io/druid/pull/5554 faster (the
-1, I think we should backport this fix first
https://github.com/druid-io/druid/pull/5815 once it gets merged, since
without it queries can silently produce incorrect results. It's not a
regression afaict, but it seems pretty major bug when the conditions that
cause it are met. Sorry for being at
Hi Gian,
Thanks for the explanation.
So, the community does not envision traditional OLTP/RT analytics use cases
like "read A-compute-write B", cross-partition consistent scans, or atomic
updates of multiple indexes? The reason I'm asking is that we also work on the
Omid transaction
Hi Anastasia,
1) At ingestion time the FactsHolder is sorted. The unsorted code path is
used by groupBy v1, which hasn't been common since groupBy v2 was made the
default a few releases ago. So I would only worry about the sorted case.
2) PlainFactsHolder is used when the user has disabled
Hi,
Recall our suggestion to use the new concurrent map named Oak as a base for
Incremental Index. Oak stands for Off-heap Allocated Keys, for more details
please see issue #5698. We had a great progress with Oak integration and
stabilizing OakIndex performance. We have some questions regarding
