You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When we are designing asset lock (#38), I found it's important to be able to efficiently query jobs by their owner (say get all pending jobs created by terra123), currently jobs are stored in an index map where key is job_id, index keys include reward and publish_time. In currently implementation, get all jobs by owner will take O(N) complexity as we need to go over all jobs, which is very slow.
More importantly, if we want to query this onchain as part of some contract execution (say query all pending jobs by owner and calculate the total locked assets as part of withdraw asset), it's likely to take too much gas when there are lots of jobs in the future, we propose 2 solutions.
Add the owner as a new index, this should reduce complexity to O(logN) I believe, but we already have 2 index keys, not sure if we should keep adding it.
Create another map key is owner, value is list of job ids from owned jobs. I prefer this approach as it's O(1) and since we only store job id in the value, it shouldn't take too much additional space.
The text was updated successfully, but these errors were encountered:
dev8723
changed the title
Improve query jobs by owner performance
Improve performance of query jobs by owner
Jul 28, 2023
When we are designing asset lock (#38), I found it's important to be able to efficiently query jobs by their owner (say get all pending jobs created by
terra123
), currently jobs are stored in an index map where key isjob_id
, index keys includereward
andpublish_time
. In currently implementation, get all jobs by owner will take O(N) complexity as we need to go over all jobs, which is very slow.More importantly, if we want to query this onchain as part of some contract execution (say query all pending jobs by owner and calculate the total locked assets as part of withdraw asset), it's likely to take too much gas when there are lots of jobs in the future, we propose 2 solutions.
The text was updated successfully, but these errors were encountered: