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
When getting ticks of popular pools, subgraph will return lots (like hundreds) of inactive pools. I.e liquidity net/gross = 0
I know I can filter this in the graphql query, and it's no skin off my nose, my machine doesn't have to do the extra processing, but seems inefficient to have this many inactive ticks returned by default, esp. on pools with tickSpacing: 1. I know that the pool contract will delete a tick once it becomes inactive. Wondering why subgraph(s) don't do the same?
Might be a good reason, thought I'd point it out and see.
The text was updated successfully, but these errors were encountered:
We could add something like store.remove("Tick", tick.id) to remove the old ticks. This can also lead to a trimmer database tables (and faster queries) if indexers are pruning really old state.
When getting ticks of popular pools, subgraph will return lots (like hundreds) of inactive pools. I.e liquidity net/gross = 0
I know I can filter this in the graphql query, and it's no skin off my nose, my machine doesn't have to do the extra processing, but seems inefficient to have this many inactive ticks returned by default, esp. on pools with
tickSpacing: 1
. I know that the pool contract will delete a tick once it becomes inactive. Wondering why subgraph(s) don't do the same?Might be a good reason, thought I'd point it out and see.
The text was updated successfully, but these errors were encountered: