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
Currently on every foreign key change, each backend has to rebuild their foreign key graph. This can be quite some overhead when using schema based sharding with many tables and many constraints, because we do a sequence scan over pg_constraint.
Two ideas on how to improve this:
Lazily build the parts of the graph that are needed. For schema based sharding it's expected that there are many small and completely disjoint graphs (one for each schema/colocation group). It does not make much sense to build all these little graphs, if you're only interested in the graph for a single schema.
Don't invalidate the full graph on a foreign key change. I'm not sure if this is even really possible.
The text was updated successfully, but these errors were encountered:
Another option could be to stop caching this graph and only get the information we need on the fly. But that would need some investigation into when we actually use this information and how expensive it is to get it.
Currently on every foreign key change, each backend has to rebuild their foreign key graph. This can be quite some overhead when using schema based sharding with many tables and many constraints, because we do a sequence scan over pg_constraint.
Two ideas on how to improve this:
The text was updated successfully, but these errors were encountered: