Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add size(Predicate) to determine the size of predicate results #8555

Closed
adasari opened this issue Jul 20, 2016 · 7 comments

Comments

Projects
None yet
5 participants
@adasari
Copy link

commented Jul 20, 2016

IMAP::Values(Predicate).szie() would return the collection for the predicate and get the size. Tracking the collection for the predicate is undesired to determine the size.

Can you add IMap::size(Predicate) which only returns size and does not care collection for the predicate?

Thanks.

@tombujok

This comment has been minimized.

Copy link
Contributor

commented Jul 20, 2016

Thanks, looks legit. Probably IMap.count(Predicate) would be a better name.

@tombujok tombujok added the Team: Core label Jul 20, 2016

@tombujok tombujok added this to the 3.8 milestone Jul 20, 2016

@tombujok

This comment has been minimized.

Copy link
Contributor

commented Dec 7, 2016

Since 3.8 you can use map.aggregate(Aggregators.count());

@tombujok tombujok closed this Dec 7, 2016

@tombujok tombujok self-assigned this Dec 7, 2016

@mzuberbhatuk

This comment has been minimized.

Copy link

commented Dec 5, 2018

Hello @tombujok
Is this feature accomplished? I checked 3.11 version but couldn't see any method like IMap.count(Predicate). Please let me know.

Thank You
Zuber

@taburet

This comment has been minimized.

Copy link
Contributor

commented Dec 5, 2018

@mzuberbhatuk you may use IMap.aggregate(Aggregators.count(), predicate) to accomplish this. As of 3.10 it won't materialize result sets if indexes are not used for a predicate evaluation, so counting is cheap; for indexed queries result sets are still materialized as of 3.11.

@mzuberbhatuk

This comment has been minimized.

Copy link

commented Dec 5, 2018

Thank you @taburet for quick reply.
Right now I am using version 3.7.3 and EntryProcessor to count the result. I have two concerns as below if you could address please.

  1. If I upgrade the hazelcast to 3.11, would it cause any issue?
  2. The use of aggregate is efficient and faster then EntryProcessor?
@taburet

This comment has been minimized.

Copy link
Contributor

commented Dec 5, 2018

  1. We are preserving backward API compatibility, so it should not cause any issues, but I still highly recommend to test the new version in a separate isolated environment before deploying to production.

  2. I guess you are using a solution like https://stackoverflow.com/a/38474504, aggregations should be faster since a final result is directly computed by Hazelcast cluster in a more efficient way. Even if you would use indexes to speed up the predicate evaluation, it still should be faster, but might be more memory hungry.

@mzuberbhatuk

This comment has been minimized.

Copy link

commented Dec 5, 2018

@taburet,
#1, agreed with you. We will first check on QA.
#2, your guess is correct. I will convert it to aggregations.

Thank you for your quick support. Highly appreciated. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.