[DB] [Migration Needed] Add indexes on _portal_domain (domain, app_id)

[pkong-ds]

Motivation

GetAppIDByDomain (WHERE domain = ?) and GetDomainsByAppID (WHERE app_id = ?) both do full table scans on _portal_domain because no index exists on either column.

The table _portal_domain grows with tenant count

• at 50k rows (in shared buffers) the domain lookup costs 1788 planner units vs 8 with the index (~210x).

Downtime

• Uses CREATE INDEX CONCURRENTLY + notransaction so the build holds no ShareLock and writes are uninterrupted — safe to apply without a downtime window.
• Drop also uses DROP INDEX CONCURRENTLY.

Tests

I asked claude to write some integration tests - which was TDD and highly detailed.'

But I think those are maintenance burden rather than helpful, so did not include in this PR

[tung2744]

Just curious what makes you find this out? Given the size of that table I think having an index should have not much performance gain?

[pkong-ds]

Just curious what makes you find this out? Given the size of that table I think having an index should have not much performance gain?

I was profiling authgear locally, to see long loading of /token /userinfo or .well-known/... are code problems.

Turns out code-level no problem - and this very, very little optimization is the only problem that claude found. So I thought, ok, doesn't hurt to open a PR for this fix, however trivial this is.

Other suspects of long loading?

• deployment specific - network latency, deployment regions, etc etc (me no access)
• blocking webhook calls - In authgear.yaml hook.blocking_handlers oidc.jwt.pre_create or oidc.id_token.pre_create
  • but these only affects /oauth2/token - so most likely deployment configuration
• dead/obsolete/not well-bookkeeped records in redis/db?
• ...