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
The current implementation of the caching stores tables as keys to invalidate the responses. This means that if any change is made to a table (or more), this will invalidate the entire cache for that table. This is inefficient, as read-heavy tables would require unnecessary caching and invalidation (aka. heavy-lifting) between the GatewayD, the cache plugin, the cache server (Redis) and the database (PostgreSQL). This means that for every update to even a single row in a table that has many cached responses in the cache server, the plugin will remove all the cached responses, effectively making subsequent queries to hit the database for a while until all those cache responses are cached.
The text was updated successfully, but these errors were encountered:
The current implementation of the caching stores tables as keys to invalidate the responses. This means that if any change is made to a table (or more), this will invalidate the entire cache for that table. This is inefficient, as read-heavy tables would require unnecessary caching and invalidation (aka. heavy-lifting) between the GatewayD, the cache plugin, the cache server (Redis) and the database (PostgreSQL). This means that for every update to even a single row in a table that has many cached responses in the cache server, the plugin will remove all the cached responses, effectively making subsequent queries to hit the database for a while until all those cache responses are cached.
The text was updated successfully, but these errors were encountered: