You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@pinot.apache.org by "atris (via GitHub)" <gi...@apache.org> on 2023/04/29 09:15:27 UTC
[GitHub] [pinot] atris opened a new pull request, #10702: Support Deletes In Upserts
atris opened a new pull request, #10702:
URL: https://github.com/apache/pinot/pull/10702
Please refer to: https://docs.google.com/document/d/17WUvE6hZwauj3_gM5cPURWSjdE2e4q9au70VeFYYx4E/edit?usp=sharing
cc @xiangfu0 @yupeng9 @kishoreg @Jackie-Jiang
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
[GitHub] [pinot] atris commented on pull request #10702: Support Deletes In Upserts
Posted by "atris (via GitHub)" <gi...@apache.org>.
atris commented on PR #10702:
URL: https://github.com/apache/pinot/pull/10702#issuecomment-1528974176
> > This won't work. We need to keep 2 bitmaps, one for valid docs and one for queryable docs. If we only keep valid docs, and count delete as removing it from the valid doc, the next event won't work as expected because we lost track of the delete event.
>
> This is precisely what we realized during our previous attempt (#10035) . Your solution isn't any different from what was attempted before.
>
There are many subtle changes from the last PR -- and this actually works for most cases except the snapshot load, which is easy to fix using the queryable map. The last PR was unable to handle out of order records and had no concept of denying partial updates on deleted records but allowing new records with the same primary key to be updated.
To answer your specific question, we are *not* losing the deleted event in this PR. That is clearly demonstrated in the unit tests.
For further details, please compare the two PRs.
> @atris : You had reached out to me via DM (on slack) to collaborate and agreed to review the existing design. Yet, you went ahead and did your own work. This is duplicated effort and not setting the right standard for committers of the Apache Pinot project.
Thank you for highlighting this. I do not wish to go into details of our 1:1 conversation here -- but my understanding was that:
1. You were planning on working this post May 10th.
2. You mentioned that it would be hard for us to collaborate since we are in different timezones.
3. I had mentioned that I have a patch I have been playing with -- and have a hard timeline.
In all honesty, I feel it is against the spirit of OSS if we "block" issues that we have not yet written code for. A good example is the issue on adding support for GROUP BY for filter aggregations -- where the issue was assigned to me, and I had a half baked PR that I did not get around finishing to. Since Evan posted a PR, I was happy to let my patch take a step back.
In this case, I only finished my PR since you mentioned that you will work on it post May 10th and would find it hard to collaborate with me -- which led me to think that our internal timelines might not be matched.
If you have any further comments, I would be happy to talk 1:1. Also, please feel free to review the PR and leave any feedback -- I would be happy to address it.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
[GitHub] [pinot] atris commented on pull request #10702: Support Deletes In Upserts
Posted by "atris (via GitHub)" <gi...@apache.org>.
atris commented on PR #10702:
URL: https://github.com/apache/pinot/pull/10702#issuecomment-1530068001
Closing this PR -- I have highlighted my concerns with the proposed design and have proposed an alternate in the attached design document. I will help land the other PR now
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
[GitHub] [pinot] atris commented on pull request #10702: Support Deletes In Upserts
Posted by "atris (via GitHub)" <gi...@apache.org>.
atris commented on PR #10702:
URL: https://github.com/apache/pinot/pull/10702#issuecomment-1529885727
> Also I hope we can agree on the direction. One key difference I can see between these two approaches is to reuse validDocId or not for deletion. I also left this comment on @navina's design. This is a key as it has implications on correctness/efficiency/complexity etc.
>
> Could you provide a detailed example on reusing validDocId is insufficient to help this discussion. Also, I'm curious what's the behavior if there's an update to record after deletion, will we ignore it or revive the record?
Please refer to the attached design document to this PR
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
[GitHub] [pinot] atris commented on pull request #10702: Support Deletes In Upserts
Posted by "atris (via GitHub)" <gi...@apache.org>.
atris commented on PR #10702:
URL: https://github.com/apache/pinot/pull/10702#issuecomment-1529282705
> This is not what I said.. I said not to directly close this PR and see if it is possible to solve the problems, and if @navina cannot get an implementation sticking with your timeline we can go with this one.
Sure, I should have been more verbose, my bad.
>Since Navina already gets an implementation #10703 and I feel that can solve all the existing problem with the overhead of keeping 2 bitmaps per segment, I'm leaning towards that solution as I don't see a good way to solve the snapshot issue with one single bitmap. The main problem with one single bitmap is that it breaks the contract that all the keys in the upsert metadata should point to a valid doc in the segment, and if we break that contract a lot of things could go wrong.
Could you please elaborate a bit more on where things could break if we had keys in upsert metadata but not in valid doc IDs?
My understanding is that the two places where things will break are:
1. Loading a segment because the deleted doc IDs will be ignored during segment reload and hence will no longer be queryable.
2. Deleting a segment because the snapshot will ignore the deleted docIDs.
I do not see anything breaking at the runtime because the access pattern defines that the upsert metadata dictates which keys to be looked up in valid doc IDs -- and since the upsert metadata has the superset of docIDs, it should not lose any data. I think this is fortified by the fact that this PR makes the change and there are no tests breaking.
Please provide your inputs
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
[GitHub] [pinot] mayankshriv commented on pull request #10702: Support Deletes In Upserts
Posted by "mayankshriv (via GitHub)" <gi...@apache.org>.
mayankshriv commented on PR #10702:
URL: https://github.com/apache/pinot/pull/10702#issuecomment-1529734544
Hi Team, reading as a neutral party seems like there were some miscommunications that led to duplicate effort on both sides. But I am 100% sure everyone here here:
- Has the best interest of the Apache Pinot project before anything.
- Would benefit from this feature being completed as soon as possible.
With above in mind, and the contribution guidelines, I do see that this [design doc ](https://docs.google.com/document/d/19s1AHCRjmqeVa0z_djYBTAt_meg6qWcUxwRO3y-G9O4/edit?usp=drivesdk) being reviewed.
My recommendation would be for all of us to collaborate on that design and any associated PRs to take this feature to completion as soon as possible.
#One Team.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
[GitHub] [pinot] navina commented on pull request #10702: Support Deletes In Upserts
Posted by "navina (via GitHub)" <gi...@apache.org>.
navina commented on PR #10702:
URL: https://github.com/apache/pinot/pull/10702#issuecomment-1528967707
> This won't work. We need to keep 2 bitmaps, one for valid docs and one for queryable docs. If we only keep valid docs, and count delete as removing it from the valid doc, the next event won't work as expected because we lost track of the delete event.
This is precisely what we realized during our previous attempt (https://github.com/apache/pinot/pull/10035) . Your solution isn't any different from what was attempted before.
@atris : You had reached out to me via DM (on slack) to collaborate and agreed to review the existing design. Yet, you went ahead and did your own work. This is duplicated effort and not setting the right standard for committers of the Apache Pinot project.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
[GitHub] [pinot] navina commented on pull request #10702: Support Deletes In Upserts
Posted by "navina (via GitHub)" <gi...@apache.org>.
navina commented on PR #10702:
URL: https://github.com/apache/pinot/pull/10702#issuecomment-1529878668
> Also I hope we can agree on the direction. One key difference I can see between these two approaches is to reuse validDocId or not for deletion. I also left this comment on @navina's design. This is a key as it has implications on correctness/efficiency/complexity etc.
> Could you provide a detailed example on reusing validDocId is insufficient to help this discussion.
I have added the reasoning in the design doc - https://docs.google.com/document/d/19s1AHCRjmqeVa0z_djYBTAt_meg6qWcUxwRO3y-G9O4/edit#heading=h.muy7y9j64ptn . can we continue the conversation in the design doc?
> Also, I'm curious what's the behavior if there's an update to record after deletion, will we ignore it or revive the record?
That's a good question. Going by the current upsert guarantees, if the event containing the update to a record has newer comparison values, it will be considered as a new record. I think it should be fine to revive it. I am not seeing any issues on doing that. Or we could make that configurable.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
[GitHub] [pinot] codecov-commenter commented on pull request #10702: Support Deletes In Upserts
Posted by "codecov-commenter (via GitHub)" <gi...@apache.org>.
codecov-commenter commented on PR #10702:
URL: https://github.com/apache/pinot/pull/10702#issuecomment-1528739296
## [Codecov](https://codecov.io/gh/apache/pinot/pull/10702?src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) Report
> Merging [#10702](https://codecov.io/gh/apache/pinot/pull/10702?src=pr&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) (3340656) into [master](https://codecov.io/gh/apache/pinot/commit/45eea269e8942dd5c031c5b1789199a6c5397cd0?el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) (45eea26) will **decrease** coverage by `18.17%`.
> The diff coverage is `0.00%`.
```diff
@@ Coverage Diff @@
## master #10702 +/- ##
=============================================
- Coverage 31.97% 13.81% -18.17%
+ Complexity 453 439 -14
=============================================
Files 2111 2058 -53
Lines 113959 111549 -2410
Branches 17196 16931 -265
=============================================
- Hits 36433 15405 -21028
- Misses 74234 94885 +20651
+ Partials 3292 1259 -2033
```
| Flag | Coverage Δ | |
|---|---|---|
| integration1 | `?` | |
| unittests2 | `13.81% <0.00%> (-0.03%)` | :arrow_down: |
Flags with carried forward coverage won't be shown. [Click here](https://docs.codecov.io/docs/carryforward-flags?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#carryforward-flags-in-the-pull-request-comment) to find out more.
| [Impacted Files](https://codecov.io/gh/apache/pinot/pull/10702?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation) | Coverage Δ | |
|---|---|---|
| [...local/indexsegment/mutable/MutableSegmentImpl.java](https://codecov.io/gh/apache/pinot/pull/10702?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-cGlub3Qtc2VnbWVudC1sb2NhbC9zcmMvbWFpbi9qYXZhL29yZy9hcGFjaGUvcGlub3Qvc2VnbWVudC9sb2NhbC9pbmRleHNlZ21lbnQvbXV0YWJsZS9NdXRhYmxlU2VnbWVudEltcGwuamF2YQ==) | `0.00% <0.00%> (ø)` | |
| [...cal/upsert/BasePartitionUpsertMetadataManager.java](https://codecov.io/gh/apache/pinot/pull/10702?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-cGlub3Qtc2VnbWVudC1sb2NhbC9zcmMvbWFpbi9qYXZhL29yZy9hcGFjaGUvcGlub3Qvc2VnbWVudC9sb2NhbC91cHNlcnQvQmFzZVBhcnRpdGlvblVwc2VydE1ldGFkYXRhTWFuYWdlci5qYXZh) | `0.00% <0.00%> (ø)` | |
| [...t/ConcurrentMapPartitionUpsertMetadataManager.java](https://codecov.io/gh/apache/pinot/pull/10702?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-cGlub3Qtc2VnbWVudC1sb2NhbC9zcmMvbWFpbi9qYXZhL29yZy9hcGFjaGUvcGlub3Qvc2VnbWVudC9sb2NhbC91cHNlcnQvQ29uY3VycmVudE1hcFBhcnRpdGlvblVwc2VydE1ldGFkYXRhTWFuYWdlci5qYXZh) | `0.00% <0.00%> (ø)` | |
| [...not/segment/local/upsert/PartialUpsertHandler.java](https://codecov.io/gh/apache/pinot/pull/10702?src=pr&el=tree&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation#diff-cGlub3Qtc2VnbWVudC1sb2NhbC9zcmMvbWFpbi9qYXZhL29yZy9hcGFjaGUvcGlub3Qvc2VnbWVudC9sb2NhbC91cHNlcnQvUGFydGlhbFVwc2VydEhhbmRsZXIuamF2YQ==) | `0.00% <0.00%> (ø)` | |
... and [760 files with indirect coverage changes](https://codecov.io/gh/apache/pinot/pull/10702/indirect-changes?src=pr&el=tree-more&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation)
:mega: We’re building smart automated test selection to slash your CI/CD build times. [Learn more](https://about.codecov.io/iterative-testing/?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=The+Apache+Software+Foundation)
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
[GitHub] [pinot] atris commented on pull request #10702: Support Deletes In Upserts
Posted by "atris (via GitHub)" <gi...@apache.org>.
atris commented on PR #10702:
URL: https://github.com/apache/pinot/pull/10702#issuecomment-1528969242
> This won't work. We need to keep 2 bitmaps, one for valid docs and one for queryable docs. If we only keep valid docs, and count delete as removing it from the valid doc, the next event won't work as expected because we lost track of the delete event.
>
> This is already a design (#10452) that covers this, so let's not duplicate the work.
>
> @navina will post the implementation soon
@Jackie-Jiang and myself discussed offline, and we have agreed to iterate on this PR -- and look on solving the snapshot of validDocID map issues.
The main issue that I wish to avoid is the separate map for queryable docIDs. The three issues we face today with the tombstone approach are:
1. Losing the deleted docID when the consuming segment seals.
2. The delete tombstone record not loading when we snapshot validDocIDs.
3. Losing the deleted timestamp and hence not able to handle out of order events.
This PR solves 3. by maintaining the full record of deletion in the segment and the primary key index -- as is demonstrated in the added unit tests. For 1, it does not matter as long as we are able to rebuild the primary key index with the deleted primary key records present.
The main challenge is 2, and we need to think about it a bit more. Will keep the group posted.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
[GitHub] [pinot] Jackie-Jiang commented on pull request #10702: Support Deletes In Upserts
Posted by "Jackie-Jiang (via GitHub)" <gi...@apache.org>.
Jackie-Jiang commented on PR #10702:
URL: https://github.com/apache/pinot/pull/10702#issuecomment-1529149862
> @Jackie-Jiang and myself discussed offline, and we have agreed to iterate on this PR -- and look on solving the snapshot of validDocID map issues.
>
> The main issue that I wish to avoid is the separate map for queryable docIDs.
This is not what I said.. I said not to directly close this PR and see if it is possible to solve the problems, and if @navina cannot get an implementation sticking with your timeline we can go with this one.
Since Navina already gets an implementation #10703 and I feel that can solve all the existing problem with the overhead of keeping 2 bitmaps per segment, I'm leaning towards that solution as I don't see a good way to solve the snapshot issue with one single bitmap. The main problem with one single bitmap is that it breaks the contract that all the keys in the upsert metadata should point to a valid doc in the segment, and if we break that contract a lot of things could go wrong.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
[GitHub] [pinot] atris closed pull request #10702: Support Deletes In Upserts
Posted by "atris (via GitHub)" <gi...@apache.org>.
atris closed pull request #10702: Support Deletes In Upserts
URL: https://github.com/apache/pinot/pull/10702
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
[GitHub] [pinot] yupeng9 commented on pull request #10702: Support Deletes In Upserts
Posted by "yupeng9 (via GitHub)" <gi...@apache.org>.
yupeng9 commented on PR #10702:
URL: https://github.com/apache/pinot/pull/10702#issuecomment-1529840410
> Hi Team, reading with a neutral perspective, it seems like there were some miscommunications that led to duplicate effort on both sides. But I am 100% sure everyone here here:
>
> * Has the best interest of the Apache Pinot project before anything.
> * Would benefit from this feature being completed as soon as possible.
>
> With above in mind, and the contribution guidelines, I do see that this [design doc ](https://docs.google.com/document/d/19s1AHCRjmqeVa0z_djYBTAt_meg6qWcUxwRO3y-G9O4/edit?usp=drivesdk) being reviewed.
>
> My recommendation would be for all of us to collaborate on that design and any associated PRs to take this feature to completion as soon as possible.
>
> Thank you all! #One Team.
+1 to #One Team
Also I hope we can agree on the direction. One key difference I can see between these two approaches is to reuse validDocId or not for deletion. I also left this comment on @navina's design. This is a key as it has implications on correctness/efficiency/complexity etc.
Could you provide a detailed example on reusing validDocId is insufficient to help this discussion. Also, I'm curious what's the behavior if there's an update to record after deletion, will we ignore it or revive the record?
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org
[GitHub] [pinot] navina commented on pull request #10702: Support Deletes In Upserts
Posted by "navina (via GitHub)" <gi...@apache.org>.
navina commented on PR #10702:
URL: https://github.com/apache/pinot/pull/10702#issuecomment-1529399018
> Thank you for highlighting this. I do not wish to go into details of our 1:1 conversation here -- but my understanding was that:
>
> 1. You were planning on working this post May 10th.
> 2. You mentioned that it would be hard for us to collaborate since we are in different timezones.
> 3. I had mentioned that I have a patch I have been playing with -- and have a hard timeline.
While all those are true, I told you that my design was open for feedback and you agreed to review it.
Obviously, I also have a local patch that I was working based on my design. Per Apache Pinot's guidelines (https://docs.pinot.apache.org/developers/developers-and-contributors/contribution-guidelines), I was taking ownership of the GitHub issue and sharing design for feedback.
> In this case, I only finished my PR since you mentioned that you will work on it post May 10th and would find it hard to collaborate with me -- which led me to think that our internal timelines might not be matched.
You didn't communicate your timeline in our conversation nor did you explain the use-case when I asked.
I am not aware of how you communicated the handover of your group by issue to another contributor and I don't think it is relevant to the tasks I own.
I have put in effort in this work and have shared my design ( https://docs.google.com/document/d/19s1AHCRjmqeVa0z_djYBTAt_meg6qWcUxwRO3y-G9O4/edit?usp=drivesdk ) and PR ( https://github.com/apache/pinot/pull/10703 ) for review.
Thanks!
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@pinot.apache.org
For additional commands, e-mail: commits-help@pinot.apache.org