Proposal: Composite Queries

Any version of the ic-cdk that allows #[query(composite = true)] should work on mainnet right? We’ve had this implemented in Azle and Kybra for a long time now, and I assume they’ll just work on mainnet without having to update ic-cdk, ic-cdk-macros, and candid?

1 Like

It looks like this is live, the replica binary has been adopted and all subnets updated. Can anyone confirm?

1 Like

Yes, now it should work. Once the a new dfx with candid 0.9.0 is released, then you would also need to change query to composite_query in the did files of examples.

Yes, I confirm this: all application and verified application subnets should have composite queries now.

1 Like

Any update on TAT for new dfx version with composite query? We are in middle of implementing our canisters and it would be helpful to know if dfx is planned to be released in coming days or weeks!

TIA

New pre-release 0.15.0-beta.1 has Candid 0.9.0, see release notes.

You can install with
DFX_VERSION=0.15.0-beta.1 sh -ci "$(curl -fsSL https://internetcomputer.org/install.sh )"

5 Likes

Thank you! Will try it.

@domwoe we tried using composite queries. A couple of questions:

1- Can we test composite queries on the mainnet using beta SDK, or it’s only for local?
2- Also will it work on all subnet canisters or only on specific subnet canisters?

TIA

  1. Composite queries are enabled on the mainnet as well as local dfx.
  2. You can a query method of any canister on the same subnet.

More information

7 Likes

Is there a plan in the future for composite queries to be supported within update calls? For example, I make an update call to a canister, and that canister makes a composite query to another canister for some data. It would be great if we could have really fast inter-canister queries in this situation.

1 Like

Yes, allowing update methods to call composite queries (a.k.a replicated execution) is planned in the future. However, we are not actively working on it right now because there are higher priority items in the roadmap.

5 Likes
  • “The instruction limit for a single call to a query method on the Internet Computer is 5 billion Wasm instructions.”
  • “The instruction limit for an update call on the Internet Computer is 20 billion Wasm instructions.”

However, I do not see specs for composite_queries. I assumed that using composite queries would have enabled us to string together longer queries. Can you confirm that composite_queries can handle no more instructions than a standard query?

I am hoping that it is not that case that in order to run large queries I need to turn them into updates and use something like heartbeat in order to call the updates and save intermediate results until a global state says that it’s complete.

Amendment #1: I see that “some special tasks, like code installation, can even go up to 200 billion instructions” which suggests that it is feasible somehow to execute that many operations.

Amendment #2: Also, I wrote my composite_query on the same canister that I called using ic_cdk::api::call to call one of its other queries. It may be possible that if the queries within the composite_query were to other canisters that it would somehow not be counted against the instruction limit for the composite_query. If that is true, it would be great for me to know. Thanks!

2 Likes

@jeshli: composite query currently has the same overall limit as a regular query. In other words, you will not gain more instructions by chaining queries.

The reason why queries have lower instruction limits than updates is because currently queries run for free. If there was a way for canister to pay for query execution, then it would be possible to bump the limit to 20B.

In general, it is a good practice to keep the queries short by maintaining the necessary data-structures in update calls such as indexes.

What is your use case that need long-running queries?

2 Likes

@ulan Thank you for clarifying the instruction limits for composite queries on the Internet Computer. I am currently developing an open-source repository for AI inference, aiming to facilitate the deployment of PyTorch/Tensorflow AI models on the IC. The primary challenge is the instruction limit for single queries: models that are within the RAM capacity of a canister often exceed the available instructions.

My initial strategy involved splitting the AI model across multiple canisters and linking them through composite queries. However, I’ve encountered the instruction limit even when testing composite queries with two individually functional queries. Since AI inference and learning processes like backpropagation don’t require updates, running them as updates seems inefficient in terms of cost, energy, and time.

Interestingly, I recently proposed the idea of allowing canisters to pay for increased query execution limits in the DeAI Technical Working Group. This approach could potentially resolve the instruction limit issue for intensive tasks like AI inference.

Moving forward, I plan to evaluate the trade-offs in terms of model speed, capability, and cost when setting the master script to run as an update as compared to a query. I have some follow-up questions: Are query calls made within an update call counted towards the instruction limit of the update? Would calling an update from an update count against the instruction limits of the outer update? Your insights on this would be greatly appreciated.

4 Likes

Thanks for explaining the use case! I agree that making an update call would be very inefficient since the update call execution is replicated on all nodes.

I replied here about query charging and your suggestion: Understanding Composite Query Instruction Limits on the Internet Computer - #2 by ulan

Let’s move the discussion into the query charging thread.

4 Likes

Hello Ulan,

In our specific use case, where multiple micro-services collaborate to serve and update data, having the capability to execute composite queries from any Update call would be highly beneficial. Is there timelines for this along with of Inter-canister Composite queries?

Best Regards