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
query_timing_ms is only used for the --experimental-model-builder. More precisely, it's used for determining the relative costs (in execution time) of different query shapes. Agora (the Gateway component that applies the indexer pricing), actually prices multi-root queries separately, for example:
Is split in 2 separate queries to be priced, and would add up the price models for tokens[...] and pairs[...].
The issue is that on the indexer side, the whole query is executed at once, and there is no way for now to determine the separate execution time of each root.
So for now, when we have a multi-root query, AA will just ignore the execution time.
We know that it is very limiting, and that is the reason for the existence of --experimental-model-builder.
Without the --experimental-model-builder, AA will apply a flat pricing model for all queries of each subgraph, and for each subgraph, will continuously optimize the flat price for maximum revenue (GRT/second).
query_timing_ms
is only used for the--experimental-model-builder
. More precisely, it's used for determining the relative costs (in execution time) of different query shapes. Agora (the Gateway component that applies the indexer pricing), actually prices multi-root queries separately, for example:Is split in 2 separate queries to be priced, and would add up the price models for
tokens[...]
andpairs[...]
.The issue is that on the indexer side, the whole query is executed at once, and there is no way for now to determine the separate execution time of each root.
So for now, when we have a multi-root query, AA will just ignore the execution time.
We know that it is very limiting, and that is the reason for the existence of
--experimental-model-builder
.Without the
--experimental-model-builder
, AA will apply a flat pricing model for all queries of each subgraph, and for each subgraph, will continuously optimize the flat price for maximum revenue (GRT/second).Originally posted by @aasseman in #37 (comment)
The text was updated successfully, but these errors were encountered: