Subgraph Best Practice 1 - Improve Query Speed with Subgraph Pruning
Reading time: 2 min
removes archival entities from the subgraph’s database up to a given block, and removing unused entities from a subgraph’s database will improve a subgraph’s query performance, often dramatically. Using indexerHints
is an easy way to prune a subgraph.
Add a section called indexerHints
in the manifest.
indexerHints
has three prune
options:
prune: auto
: Retains the minimum necessary history as set by the Indexer, optimizing query performance. This is the generally recommended setting and is the default for all subgraphs created bygraph-cli
>= 0.66.0.prune: <Number of blocks to retain>
: Sets a custom limit on the number of historical blocks to retain.prune: never
: No pruning of historical data; retains the entire history and is the default if there is noindexerHints
section.prune: never
should be selected if are desired.
We can add indexerHints
to our subgraphs by updating our subgraph.yaml
:
specVersion: 1.0.0schema:file: ./schema.graphqlindexerHints:prune: autodataSources:- kind: ethereum/contractname: Contractnetwork: mainnet
-
If are desired as well as pruning, pruning must be performed accurately to retain Time Travel Query functionality. Due to this, it is generally not recommended to use
indexerHints: prune: auto
with Time Travel Queries. Instead, prune usingindexerHints: prune: <Number of blocks to retain>
to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or useprune: never
to maintain all data. -
It is not possible to at a block height that has been pruned. If grafting is routinely performed and pruning is desired, it is recommended to use
indexerHints: prune: <Number of blocks to retain>
that will accurately retain a set number of blocks (e.g., enough for six months).
Pruning using indexerHints
is a best practice for subgraph development, offering significant query performance improvements.