Every page: two EXISTS queries ask whether the instance has accounts and whether the person has groups #1115

New issue

Closed

opened 2026-10-31 03:04:07 +00:00 by tiagoagueda · 0 comments

tiagoagueda commented

2026-10-31 03:04:07 +00:00

Owner

What exists today

src/postulo/core/context_processors.py:107 puts site.signup_open_now() in every page's context. core/site.py:300-307 returns registration_open() or is_empty(), and is_empty() (:295-297) runs get_user_model().objects.exists(). When sign-up is closed, which is the usual state, every full page runs SELECT 1 FROM accounts_user LIMIT 1.
src/postulo/templates/base.html:241 writes {% if user.groups.exists %} in the account menu, which every full page draws for a signed-in person: SELECT 1 FROM auth_group INNER JOIN accounts_user_groups ... LIMIT 1.

Both seen in the second GET of core:home under the test settings (probe audit/m_scripts/test_probe_queries.py): 20 queries, these two among them. Each is a cheap indexed lookup, so the win is in query count, not in time.

What would change

is_empty(): once an instance has an account it almost never goes back to none. Remember a false answer in the process and forget it on post_delete of the user model (a receiver that clears the flag), so the rare "every account deleted" case still opens sign-up as today.
user.groups.exists: compute it once in the context processor, only for an authenticated user, and only where the account menu is drawn; or as a has_groups attribute set once on the request. The menu item and its markup do not change.

What it saves or protects

small: two of the 20 queries on the home page (measured), on every full page for everyone signed in

Accessibility

none

Decisions

Process memo with a delete signal, or Django's cache? Recommended: the process memo with the signal; the database cache would cost a query of its own.

Found by the efficiency and reliability audit of 2026-10-30 (finding Q4; index postulo/postulo#1108). Checked against main at daee30b15 (2026-10-30).

## What exists today - `src/postulo/core/context_processors.py:107` puts `site.signup_open_now()` in every page's context. `core/site.py:300-307` returns `registration_open() or is_empty()`, and `is_empty()` (`:295-297`) runs `get_user_model().objects.exists()`. When sign-up is closed, which is the usual state, every full page runs `SELECT 1 FROM accounts_user LIMIT 1`. - `src/postulo/templates/base.html:241` writes `{% if user.groups.exists %}` in the account menu, which every full page draws for a signed-in person: `SELECT 1 FROM auth_group INNER JOIN accounts_user_groups ... LIMIT 1`. Both seen in the second GET of `core:home` under the test settings (probe `audit/m_scripts/test_probe_queries.py`): 20 queries, these two among them. Each is a cheap indexed lookup, so the win is in query count, not in time. ## What would change - `is_empty()`: once an instance has an account it almost never goes back to none. Remember a false answer in the process and forget it on `post_delete` of the user model (a receiver that clears the flag), so the rare "every account deleted" case still opens sign-up as today. - `user.groups.exists`: compute it once in the context processor, only for an authenticated user, and only where the account menu is drawn; or as a `has_groups` attribute set once on the request. The menu item and its markup do not change. ## What it saves or protects small: two of the 20 queries on the home page (measured), on every full page for everyone signed in ## Accessibility none ## Decisions - **Process memo with a delete signal, or Django's cache?** Recommended: the process memo with the signal; the database cache would cost a query of its own. --- Found by the efficiency and reliability audit of 2026-10-30 (finding Q4; index postulo/postulo#1108). Checked against `main` at `daee30b15` (2026-10-30).

tiagoagueda added this to the 0.6.0 milestone

2026-10-31 03:04:07 +00:00

tiagoagueda added the

performance

enhancement

labels

2026-10-31 03:04:07 +00:00

tiagoagueda referenced this issue

2026-10-31 03:04:40 +00:00

Efficiency and reliability audit of 2026-10-30: index #1108

tiagoagueda referenced this issue from a pull request that will close it,

2026-11-10 23:08:20 +00:00