Context loading optimization for schema based multi-tenant workloads

[olirice]

What kind of change does this PR introduce?

DDL changes in any schema force a full context (schema) reload for all connections.

We don't want to change that behavior because invalidating subsections of the GraphQL schema based on SQL DDL would require significant refactoring and be error prone.

Projects using schema based multi-tenancy are negatively impacted by these choices because

• Updates in any isolated tenant require reloading the schema for all tenants
• Since all schemas are loaded for all tenants (regardless of search path) the query to reload context slows down with each additional tenant

This PR filters visible schemas (tables/functions/types/etc) during context reload by if the current_user has USAGE privilege.

This change does not solve the issue that DDL in any tenant's DB causes a refresh for all connections, but it does allow the context loading query time to be invariant to the number of tenants in the database.

Note: filtering by search_path is not a viable alternative because we support referencing types that aren't on the current search path

[olirice]

@etherealhedgehog @magrinj this solution should work for you so long as each of your tenants connects to the database with a dedicated role and each of those roles does not have USAGE permission on the schemas for the other tenants.

Any thoughts would be great. Performance impact on your projects would be even better if possible

ref #480

[etherealhedgehog]

@olirice Thank you for looking at this. We use pg_graphql to serve a public API to our users so they can access data within their tenant. Our tenants tend to have lots of data ingested into our system that we make available to them in real-time, so query performance is critical for us. We currently filter solely based on search path, but I think we should be able to supplement that by setting the role on the connection dynamically based on the tenant. For us, this should be a workable solution.

[olirice]

@magrinj your buy-in here would go a long way to getting this merged if you have a few minutes to review

[magrinj]

Hey @olirice sorry for the delay, and thanks for this proposal, we'll try to take a look on that this week 🙂
Like @etherealhedgehog we're using search_path, so basing that on the current_user will require some changes on our side to test that on a production dump and see if performance are improved.
@charlesBochet will keep you in touch on that !

[olirice]

Awesome, thanks!

[olirice]

any word @magrinj ?

[martmull]

Hey @olirice, apologies for the lengthy period of silence. We've conducted tests on this optimization across more than 600 schemas. The results were significant; we managed to reduce the duration of the first request from over 2 seconds to under 200 milliseconds, which is quite impressive. Given these outcomes, I believe we can proceed with this approach. Cheers
@magrinj

[olirice]

awesome, thank you for following up!

We'll get this approved and merged