Docs
Buscar⌘ K
  • Inicio
  • Acerca de The Graph
  • Redes Admitidas
  • Protocol Contracts
  • Subgrafos
    • Corrientes secundarias
      • Token API
        • AI Suite
          • Indexación
            • Recursos
              Subgrafos > Best Practices

              2 minutos

              Subgraph Best Practice 1 - Improve Query Speed with Subgraph Pruning

              TLDR

              Pruning 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.

              How to Prune a Subgraph With indexerHints

              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 by graph-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 no indexerHints section. prune: never should be selected if Time Travel Queries are desired.

              We can add indexerHints to our Subgraphs by updating our subgraph.yaml:

              1specVersion: 1.3.02schema:3  file: ./schema.graphql4indexerHints:5  prune: auto6dataSources:7  - kind: ethereum/contract8    name: Contract9    network: mainnet

              Important Considerations

              • If Time Travel Queries 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 using indexerHints: prune: <Number of blocks to retain> to accurately prune to a block height that preserves the historical data required by Time Travel Queries, or use prune: never to maintain all data.

              • It is not possible to graft 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).

              Conclusion

              Pruning using indexerHints is a best practice for Subgraph development, offering significant query performance improvements.

              Subgraph Best Practices 1-6

              1. Improve Query Speed with Subgraph Pruning

              2. Improve Indexing and Query Responsiveness by Using @derivedFrom

              3. Improve Indexing and Query Performance by Using Immutable Entities and Bytes as IDs

              4. Improve Indexing Speed by Avoiding eth_calls

              5. Simplify and Optimize with Timeseries and Aggregations

              6. Use Grafting for Quick Hotfix Deployment

              ⁠Editar en GitHub⁠

              Smart Contract Analysis with Cana CLIArrays with @derivedFrom
              En esta página
              • TLDR
              • How to Prune a Subgraph With indexerHints
              • Important Considerations
              • Conclusion
              • Subgraph Best Practices 1-6
              The GraphEstadoTestnetRecursos de marcaForoSeguridadPolítica de privacidadTérminos de servicio