So, let's say we had the necessary ram, cpu, and net to store a lot of records in a multi_index table. (100,000 to 1,000,000). Considering that a transaction in EOS has a max execution time (150 ms), we make individual transactions performing the following operations:

  1. Find a specific row by primary key.
  2. Looping all the records

Would any of this transactions fail for exceeding 150 ms?

What are the alternatives for storing and querying through a lot of records?

  • For looping through all records, I wouldn't be at all surprised to have the transaction fail for exceeding the time limit. I have written methods that need to clean data out of a multi_index table, and they will fail just trying to remove rows when the row count gets too high. Nov 13, 2018 at 19:42

1 Answer 1

  1. Find by primary key is an efficient operation and will scale with your table size.

  2. Looping over every row is not something you want to do in the smart contract in a direct way. The risk is you will hit the limit for a single transaction time.

You can use demux to have a copy of the table data in an off chain table. Loop over the rows there and if you need to change, send an action to change the rows you need.

Another option is to add a variable to follow the index you reached and loop in "pages" so each transaction is below the limit and you will complete the operation successfully in several such operations. Personally I would go with demux, rarely you need a pure on chain solution.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.